|
|
|
|
|
|
| Author |
Message |
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
 Posted: Sat May 27, 2006 9:18 pm Post subject:
A sort of plan for consoles in FreeBSD
|
|
|
We have four concepts of "console" in FreeBSD:
1. Whatever boot0/boot1/boot2/loader uses
Accessed from/via native boot/firmware environment
2. The boot/DDB/printf(9)/panic(9) console ("The low-level console").
Polled operation since interrupts may not be working.
3. The tty which /sbin/init uses for single-user and /etc/rc
Can be any tty, but convention has been "/dev/console"
4. The /dev/console device in multi-user mode.
Emergency output device for critical messages.
Most often they will all four end up referring to the same piece
of hardware (a good thing), but do not let this confuse you into
beliving they are one and the same thing.
The problem I'm trying to solve involves #4, the /dev/console device
which currently has a rather nasty way of forcing the underlying
console device driver open.
Seen in the light of history, spitting messages out on /dev/console
was the right thing to do back in the 1980ies, but the operators,
(or tape-monkeys as we were called back then), and their DecWriter
terminals hooked up to the VAX780 computers exist only in museums
these days, and they didn't run FreeBSD7 anyway.
Today we expect all relevant logging to happen to logfiles, either
directly (like for instance apache provides for) or via syslogd( ,
which adds the ability to send the logs to a remote machine in
real-time.
Spitting things out on /dev/console today will more likely than
not, print stuff on a syscons or serial port which nobody looks at.
For that reason, we added a hack to the kernel to make all stuff
that went to /dev/console be sent to syslogd(.
I would like to redefine the semantics of "/dev/console" as follows:
if any console-consumers like xconsole( are active
send output to all console-consumers.
else if a controlling terminal is available
send output to controlling terminal (that is /dev/tty)
else
send output to syslogd, as if generated by printf(9).
(but do not actually output to low-level console)
If xconsole( or similar programs are run, or if syslogd( is
told to record all console output, they will get what they expect.
Alternatively, we try to send the message to the relevant user and
if that fails (for daemons) we log it in syslog.
This also involves number #3 from the list because today /sbin/init
opens /dev/console for single user mode and /etc/rc. But /sbin/init
can use any tty device so adding the necessary code to make the
low-level console communicate the relevant tty name to /sbin/init,
possibly making it overridable from the loader with a hint, will
take care of that.
Comments, ideas, suggestions etc welcome
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
 |
gnn@freebsd.org
*nix forums beginner
Joined: 11 Aug 2005
Posts: 15
|
| Posted: Sun May 28, 2006 12:05 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
At Sat, 27 May 2006 23:18:24 +0200,
Poul-Henning Kamp wrote:
| Quote: | Comments, ideas, suggestions etc welcome
|
It makes sense to me. I know that by default all the stuff I would
expect on the console will wind up in /var/log/messages but do we want
to create a /var/log/console that takes the place of console output in
the last case?
Later,
George
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Doug Barton
*nix forums addict
Joined: 24 Apr 2002
Posts: 91
|
| Posted: Sun May 28, 2006 1:05 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
Poul-Henning Kamp wrote:
| Quote: | Today we expect all relevant logging to happen to logfiles, either
directly (like for instance apache provides for) or via syslogd(,
which adds the ability to send the logs to a remote machine in
real-time.
Spitting things out on /dev/console today will more likely than
not, print stuff on a syscons or serial port which nobody looks at.
For that reason, we added a hack to the kernel to make all stuff
that went to /dev/console be sent to syslogd(.
|
I really like that hack, and enable logging of console.* on all my systems.
Your point about syslogd being able to log remotely is also a good one.
However the good old fashioned /dev/console is not as anachronistic as you
might think. Where I used to work we had a very handy serial console program
that "listened" to the serial console output and logged it locally. That
way, if a machine crashed, died, or otherwise went unreachable you could log
into the serial console, quickly check the most recent console output, then
try to fix the problem. Whatever output might have gone to a remote syslog
is also useful, but only if the problems were not so fundamental as to have
prevented the remote logging in the first place.
| Quote: | I would like to redefine the semantics of "/dev/console" as follows:
if any console-consumers like xconsole( are active
send output to all console-consumers.
else if a controlling terminal is available
send output to controlling terminal (that is /dev/tty)
else
send output to syslogd, as if generated by printf(9).
(but do not actually output to low-level console)
|
At first glance I don't see anything wrong with that logic. My one request
is that you add a branch that says, "if legacy behavior is requested by
<some configuration method>, add it to the mix."
hth,
Doug
--
This .signature sanitized for your protection
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
| Posted: Sun May 28, 2006 5:12 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
Poul-Henning Kamp wrote:
| Quote: | We have four concepts of "console" in FreeBSD:
1. Whatever boot0/boot1/boot2/loader uses
Accessed from/via native boot/firmware environment
|
#1 is sort of independent as it stops being used at the moment FreeBSd starts.
| Quote: |
2. The boot/DDB/printf(9)/panic(9) console ("The low-level console").
Polled operation since interrupts may not be working.
|
I always want this to be set to be the same device as #1.
(with dcons that is already not possible)
| Quote: |
3. The tty which /sbin/init uses for single-user and /etc/rc
Can be any tty, but convention has been "/dev/console"
|
I would want this to be the same device as #2
| Quote: |
4. The /dev/console device in multi-user mode.
Emergency output device for critical messages.
|
but, emergency messages from where? You've coverred the ones I care about above.
My main concern is that when I have a single serial console,
All these things are captured on the session logger that is monitoring it.
As long as that can happen I'm not too worried about how that happens.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
| Posted: Sun May 28, 2006 5:15 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
gnn@freebsd.org wrote:
| Quote: | At Sat, 27 May 2006 23:18:24 +0200,
Poul-Henning Kamp wrote:
Comments, ideas, suggestions etc welcome
It makes sense to me. I know that by default all the stuff I would
expect on the console will wind up in /var/log/messages but do we want
to create a /var/log/console that takes the place of console output in
the last case?
|
The trouble with /var/log/messages is that you need to have a functionning
disk system and a fully working scheduler etc. for the message to get there.
When everything gumms up you need to still get those last whimpers out.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Lyndon Nerenberg
*nix forums beginner
Joined: 21 Oct 2002
Posts: 6
|
| Posted: Sun May 28, 2006 6:12 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
Just as a neutral data point ...
CTIX (Convergent Technologies SVRx from the mid 1980s) ran /dev/
console such that writes went into an in-kernel circular buffer.
Reads from /dev/console would drain the contents of that buffer.
I didn't like the read behaviour; it would have been more useful if
reads didn't empty the buffer. But I did like how easy it was to
examine the buffer with crash after a panic. While this isn't
directly applicable to BSD, I do like the concept of having that
kernel message log. It addresses the issues that others have raised
about syslog not having time to commit to disk, or do a network write
during kernel death. I would gladly pay for a meg or so of kernel
memory to hold such a write buffer (size tunable by sysctl).
--lyndon
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Peter Jeremy
*nix forums addict
Joined: 13 Jun 2002
Posts: 77
|
| Posted: Sun May 28, 2006 6:21 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
On Sat, 2006-May-27 22:12:38 -0700, Julian Elischer wrote:
| Quote: | Poul-Henning Kamp wrote:
We have four concepts of "console" in FreeBSD:
1. Whatever boot0/boot1/boot2/loader uses
Accessed from/via native boot/firmware environment
#1 is sort of independent as it stops being used at the moment FreeBSd
starts.
|
Last time I checked, the copyright notice and some of the early kernel
probe output came via the native firmware (at least on some
architectures). There's a bit of a Catch-22 because the kernel wants
to report output before it's got far enough through the device probe
sequence to be able to talk to the hardware making up the console.
| Quote: | 4. The /dev/console device in multi-user mode.
Emergency output device for critical messages.
but, emergency messages from where? You've coverred the ones I care about
above.
|
syslog(3) LOG_CONS immediately comes to mind. A quick check of the
source shows that ps(1), init(, rpc.ypxfrd(, bits of the lp
subsystem as well as thread library's initialisation code can also
write to /dev/console.
I thought dump( did but it doesn't appear to any longer.
--
Peter Jeremy
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Peter Jeremy
*nix forums addict
Joined: 13 Jun 2002
Posts: 77
|
| Posted: Sun May 28, 2006 6:26 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
On Sat, 2006-May-27 23:12:29 -0700, Lyndon Nerenberg wrote:
| Quote: | reads didn't empty the buffer. But I did like how easy it was to
examine the buffer with crash after a panic. While this isn't
directly applicable to BSD, I do like the concept of having that
kernel message log.
|
FreeBSD has had a message buffer as long as I can remember. Look in
<sys/msgbuf.h> for the API and kern.msgbuf for the content. I can't
find any man pages on it.
--
Peter Jeremy
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Lyndon Nerenberg
*nix forums beginner
Joined: 21 Oct 2002
Posts: 6
|
| Posted: Sun May 28, 2006 6:45 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
On May 27, 2006, at 11:26 PM, Peter Jeremy wrote:
| Quote: | FreeBSD has had a message buffer as long as I can remember. Look in
sys/msgbuf.h> for the API and kern.msgbuf for the content. I can't
find any man pages on it.
|
I remember looking at this before a couple of times, but it seemed
(I'm a bit fuzzy on the details now -- it's been a while) that the
interface wasn't stable (or even documented, as you mentioned).
If a documented API was nailed down, that would be great. But I
would really like to see the read semantics of /dev/console made as I
described, so that multiple readers could watch what was going on
(e.g. multiple procs filtering the output and acting accordingly).
This makes it much easier to write system monitors (ala swatch, doing
the equivalent of 'tail -f') without having to do all kinds of ioctl
goo against special /dev files.
Being able to adjust the buffer size at runtime (via sysctl) would be
a bonus. For example, when we get load storms on our web servers, it
would be very helpful to be able to crank up the size of the buffer
and turn up logging to try to catch something in the debug stream to
explain what's going on. But I wouldn't want to run with a (say)
200MB console buffer in normal production. Dynamic sizing is perhaps
just wishful thinking though -- we can certainly live without it.
--lyndon
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
M. Warner Losh
*nix forums Guru
Joined: 22 Mar 2002
Posts: 365
|
| Posted: Sun May 28, 2006 7:15 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
In message: <16029.1148764704@critter.freebsd.dk>
Poul-Henning Kamp <phk@phk.freebsd.dk> writes:
: 4. The /dev/console device in multi-user mode.
: Emergency output device for critical messages.
Who is generating these messages? Are these for the programs that
open /dev/console and spit out 'oh s**t' messages? If so, why not
make /dev/console a pipe that syslogd listens to? #3 can be solved by
using a different name. Hmmm, I guess it would have to be a special
kind of pipe where all writers go to the same readers since you'd
want the output from #2 to go down this pipe as well.
: I would like to redefine the semantics of "/dev/console" as follows:
: if any console-consumers like xconsole( are active
: send output to all console-consumers.
: else if a controlling terminal is available
: send output to controlling terminal (that is /dev/tty)
: else
: send output to syslogd, as if generated by printf(9).
: (but do not actually output to low-level console)
Assuming that this is for #4 /dev/console, that's fine. If you are
talking about #2 or #3, then we have problems. The problem that I
have with it being just /dev/tty is that the program opened
/dev/console to tell the world about it, rather than just using
fprintf(stderr,). What does that gain you? Things like syslog
already log to stderr as well as /dev/console (when told to do both).
This would remove most syslog messages from the logs if they were from
programs with controlling ttys (all nondaemons).
: If xconsole( or similar programs are run, or if syslogd( is
: told to record all console output, they will get what they expect.
: Alternatively, we try to send the message to the relevant user and
: if that fails (for daemons) we log it in syslog.
I'm not sure that I see the point of sending it to the actual user.
Things like syslog already have an option to print to stderr as well
as /dev/console. I think that muddies the waters.
: This also involves number #3 from the list because today /sbin/init
: opens /dev/console for single user mode and /etc/rc. But /sbin/init
: can use any tty device so adding the necessary code to make the
: low-level console communicate the relevant tty name to /sbin/init,
: possibly making it overridable from the loader with a hint, will
: take care of that.
Indeed, it would.
: Comments, ideas, suggestions etc welcome
Warner
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
M. Warner Losh
*nix forums Guru
Joined: 22 Mar 2002
Posts: 365
|
| Posted: Sun May 28, 2006 7:19 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
In message: <20060528062113.GN744@turion.vk2pj.dyndns.org>
Peter Jeremy <peterjeremy@optushome.com.au> writes:
: On Sat, 2006-May-27 22:12:38 -0700, Julian Elischer wrote:
: >Poul-Henning Kamp wrote:
: >>We have four concepts of "console" in FreeBSD:
: >>
: >>1. Whatever boot0/boot1/boot2/loader uses
: >> Accessed from/via native boot/firmware environment
: >
: >#1 is sort of independent as it stops being used at the moment FreeBSd
: >starts.
:
: Last time I checked, the copyright notice and some of the early kernel
: probe output came via the native firmware (at least on some
: architectures). There's a bit of a Catch-22 because the kernel wants
: to report output before it's got far enough through the device probe
: sequence to be able to talk to the hardware making up the console.
There's special code in the kernel that knows how to talk to the
hardware before it has been fully probed. All the early boot messages
are printed out using this low-level console. This is #2 in phk's
world. Some platforms tie this low-level console to the firmware from
#1, but i386, amd64, pc98, ia64 and arm (maybe others too) all go
directly to real hardware using the low-level console routines.
: >>4. The /dev/console device in multi-user mode.
: >> Emergency output device for critical messages.
: >
: >but, emergency messages from where? You've coverred the ones I care about
: >above.
:
: syslog(3) LOG_CONS immediately comes to mind. A quick check of the
: source shows that ps(1), init(, rpc.ypxfrd(, bits of the lp
: subsystem as well as thread library's initialisation code can also
: write to /dev/console.
LOG_CONS happens only when it can't sent the message to syslogd(.
LOG_PERROR will also print it on stderr. LOG_CONS would then
degenerate into LOG_PERROR. If the data can't already be sent to
syslogd( by userland, I'm not so sure that the kernel would have
better luck.
: I thought dump( did but it doesn't appear to any longer.
dump used to, but now uses wall.
Warner
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Sun May 28, 2006 8:00 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
In message <20060528.011932.1220016372.imp@bsdimp.com>, "M. Warner Losh" writes
:
| Quote: | LOG_CONS happens only when it can't sent the message to syslogd(.
LOG_PERROR will also print it on stderr. LOG_CONS would then
degenerate into LOG_PERROR.
|
No, it would degenerate into the nonexistent LOG_TTY.
stderr and /dev/tty are not the same thing, and it is impossible to
declare one better than the other: they have different semantics.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Sun May 28, 2006 8:05 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
In message <20060528.011518.1306332021.imp@bsdimp.com>, "M. Warner Losh" writes
:
| Quote: | In message: <16029.1148764704@critter.freebsd.dk
Poul-Henning Kamp <phk@phk.freebsd.dk> writes:
: 4. The /dev/console device in multi-user mode.
: Emergency output device for critical messages.
Who is generating these messages?
|
Typically programs in distress.
| Quote: | If so, why not make /dev/console a pipe that syslogd listens to?
|
That is the option which I personally favour.
It kills xconsole(1) like applications, and I suspect that would
result in whinage, but if we are willing to do that, it is by
far the simplest and most sensible solution.
| Quote: | : I would like to redefine the semantics of "/dev/console" as follows:
: if any console-consumers like xconsole( are active
: send output to all console-consumers.
: else if a controlling terminal is available
: send output to controlling terminal (that is /dev/tty)
: else
: send output to syslogd, as if generated by printf(9).
: (but do not actually output to low-level console)
Assuming that this is for #4 /dev/console, that's fine.
|
It is only #4.
| Quote: | The problem that I
have with it being just /dev/tty is that the program opened
/dev/console to tell the world about it, rather than just using
fprintf(stderr,). What does that gain you?
|
As I said in the other email, /dev/tty and stderr is not quite the
same thing. /dev/tty has more of the semantics that /dev/console
used to have (ie: flash it before their eyes).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Sun May 28, 2006 8:07 am Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
In message <4478F767.5090403@FreeBSD.org>, Doug Barton writes:
| Quote: | At first glance I don't see anything wrong with that logic. My one request
is that you add a branch that says, "if legacy behavior is requested by
some configuration method>, add it to the mix."
|
Legacy behaviour is exactly what we need to avoid to get the
device locking sorted out, so this would be rather poisonous
to the entire effort.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
| Posted: Sun May 28, 2006 3:27 pm Post subject:
Re: A sort of plan for consoles in FreeBSD
|
|
|
Poul-Henning Kamp wrote:
| Quote: | In message <20060528.011518.1306332021.imp@bsdimp.com>, "M. Warner Losh" writes
:
In message: <16029.1148764704@critter.freebsd.dk
Poul-Henning Kamp <phk@phk.freebsd.dk> writes:
: 4. The /dev/console device in multi-user mode.
: Emergency output device for critical messages.
Who is generating these messages?
Typically programs in distress.
If so, why not make /dev/console a pipe that syslogd listens to?
That is the option which I personally favour.
It kills xconsole(1) like applications, and I suspect that would
result in whinage, but if we are willing to do that, it is by
far the simplest and most sensible solution.
killing XConsole is not a small matter. people have that when they are |
specifically looking for that information
| Quote: |
: I would like to redefine the semantics of "/dev/console" as follows:
: if any console-consumers like xconsole( are active
: send output to all console-consumers.
: else if a controlling terminal is available
: send output to controlling terminal (that is /dev/tty)
: else
: send output to syslogd, as if generated by printf(9).
: (but do not actually output to low-level console)
Assuming that this is for #4 /dev/console, that's fine.
It is only #4.
The problem that I
have with it being just /dev/tty is that the program opened
/dev/console to tell the world about it, rather than just using
fprintf(stderr,). What does that gain you?
As I said in the other email, /dev/tty and stderr is not quite the
same thing. /dev/tty has more of the semantics that /dev/console
used to have (ie: flash it before their eyes).
_______________________________________________ |
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Fri Jan 09, 2009 5:46 am | All times are GMT
|
|
Loans | Car Finance | Magic the Gathering | Credit Cards | Debt Help
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
