|
|
|
|
|
|
| Author |
Message |
Scott Long
*nix forums Guru Wannabe
Joined: 16 Jun 2002
Posts: 167
|
 Posted: Tue May 23, 2006 5:20 am Post subject:
Re: misc questions about the device&driver arch
|
|
|
william wallace wrote:
[...]
| Quote: | MSI:
I've bantered around different suggestions for an API that will support
this. The basic thing that a driver needs from this is to know
exactly how many message interrupt vectors are available to it. It
can't just register vectors and handlers blindly since the purpose of
MSI is to assign special meanings to each vector and allow the driver to
handle each one in specifically.
|
[...]
I just wanted to briefly say that an MSI implementation has been done
recently, and that it should start getting wider circulation and review
soon. That's not to say that more work and design can't be done in this
area, but we should probably wait a bit and see what has been done
already.
Scott
_______________________________________________
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 |
|
 |
Alexander Leidinger
*nix forums addict
Joined: 16 Jun 2002
Posts: 59
|
| Posted: Tue May 23, 2006 6:21 am Post subject:
Re: doxygen target (was: Re: cvs commit: src Makefile.inc1 ObsoleteFiles.inc src/etc/defaults rc.conf src/etc/mtree BSD.usr.dist src/etc/rc.d Makefile isdnd pcvt syscons src/release/picobsd/build picobsd src/share/man/man4 Makefile atkbd.4 kbdmux.4 pcvt.4
|
|
|
Quoting gnn@freebsd.org (from Mon, 22 May 2006 16:50:11 -0700):
| Quote: | At Mon, 22 May 2006 10:18:25 +0200,
Alexander Leidinger wrote:
Regarding the make target, do you think about "cd /usr/src; make
doxygen" or about "cd /usr/src/<mumble>; make doxygen"?
Yes  It hsould be possible to be as specific or non-specific as
possible. There can then be nightly builds of the docs, much like
running global nightly to get cross references like I put up on
codespelunking.org
|
I try to come up with the /usr/src doxygen target first.
| Quote: | The targets in the .tar.bz2 generate a HTML version too. Currently
the HTML version is around 300 MB, and it only covers a small part
of the kernel. Shall the HTML version also be generated (not
available online)? What about the destination, where do you want the
HTML version and/or the PDF version (needs pdflatex as a build tool)
to be placed (I can't come up with a good destination)? The HTML
version is generated by doxygen directly, the PDF needs to be
generated from the latex version, so in case of the PDF version it
would make sense to have a "doxygen" and "doxygeninstall" target,
but not for the HTML version (except you want to generate everything
in OBJDIR and then do a copy to the destination).
Yes, I'm asking bikeshed questions... but only because I can't think
of a good answer myself ATM.
My preference, and I'm not a Doxygen guru, is that we generate HTML
from /usr/src into a /usr/doc directory, which is like /usr/obj, then
|
Sounds fine to me. One directory per subsystem if we go the split-up way.
| Quote: | some folks can serve /usr/doc on the net. Sub directory builds should
make sub-directory doc directories. I.e. /usr/src/sys/netinet/doc. I
think that /usr/src/sys is already a special root which gets a doc
directory, and I think that's fine. For now I want to emphasize
simplicity.
|
I'm not sure the subdirectory builds are that simple to implement in a
generic fashion (I have to play around with some ideas here...).
Adding a target by hand to each interesting subdirectory is easy.
| Quote: | THe other thing we need guidance on is, if people want to, how to most
easily add clear annotations to soiurce that make Doxygen happy. A
one page cheat sheet would go a long way towards making this usable by
people who don't like to write documentation
|
I think http://www.stack.nl/~dimitri/doxygen/docblocks.html provides a
good start (until someone writes doxygen_style(9) ).
A FAQ is available at http://www.stack.nl/~dimitri/doxygen/faq.html
and http://www.stack.nl/~dimitri/doxygen/commands.html contains a list
of all doxygen recognized documentation-commands.
Bye,
Alexander.
--
Selling GoodYear Eagle F1 235/40ZR18, 2x 4mm + 2x 5mm, ~150 EUR
you have to pick it up between Germany/Saarland and Luxembourg/Capellen
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
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 |
|
|
George V. Neville-Neil
*nix forums beginner
Joined: 17 Mar 2006
Posts: 3
|
| Posted: Tue May 23, 2006 11:30 pm Post subject:
Re: doxygen target (was: Re: cvs commit: src Makefile.inc1 ObsoleteFiles.inc src/etc/defaults rc.conf src/etc/mtree BSD.usr.dist src/etc/rc.d Makefile isdnd pcvt syscons src/release/picobsd/build picobsd src/share/man/man4 Makefile atkbd.4 kbdmux.4 pcvt.4
|
|
|
At Tue, 23 May 2006 08:21:15 +0200,
Alexander Leidinger wrote:
| Quote: | I'm not sure the subdirectory builds are that simple to implement in
a generic fashion (I have to play around with some ideas here...).
Adding a target by hand to each interesting subdirectory is easy.
|
OK, so probably only the set you've already done would be first.
| Quote: |
THe other thing we need guidance on is, if people want to, how to most
easily add clear annotations to soiurce that make Doxygen happy. A
one page cheat sheet would go a long way towards making this usable by
people who don't like to write documentation :-)
I think http://www.stack.nl/~dimitri/doxygen/docblocks.html provides a
good start (until someone writes doxygen_style(9) ).
|
I'll look at that.
Thanks,
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 |
|
|
Alexander Leidinger
*nix forums addict
Joined: 16 Jun 2002
Posts: 59
|
| Posted: Fri May 26, 2006 6:30 pm Post subject:
Re: doxygen target (was: Re: cvs commit: src Makefile.inc1 ObsoleteFiles.inc src/etc/defaults rc.conf src/etc/mtree BSD.usr.dist src/etc/rc.d Makefile isdnd pcvt syscons src/release/picobsd/build picobsd src/share/man/man4 Makefile atkbd.4 kbdmux.4 pcvt.4
|
|
|
Quoting "George V. Neville-Neil" <gnn@neville-neil.com> (Tue, 23 May 2006 16:30:36 -0700):
| Quote: | At Tue, 23 May 2006 08:21:15 +0200,
Alexander Leidinger wrote:
I'm not sure the subdirectory builds are that simple to implement in
a generic fashion (I have to play around with some ideas here...).
Adding a target by hand to each interesting subdirectory is easy.
OK, so probably only the set you've already done would be first.
|
I've just committed the framework. Currently it's connected to the
top-level Makefile which generates all HTML docs in OBJDIR. To build
only specific subsystems and/or the PDF docs, you have to go
to /usr/src/sys/doc/subsys and run make (you will see a message with
available targets).
The README tells you which programs you need to have installed and how
to add more subsystems.
I want to revise some defaults (e.g. destination directory, ...), but
as it is now, people can start playing around with it (and it may be
helpful for our SoC students).
Oh, yes, you need a little bit of time or a very fast machine to
generate all docs.
In case someone wants to improve the framework, go ahead. I will not
add further subsystems soon (except someone sends in a config for it)
or change the doxygen configuration. My goals for the near term are to
talk with doc@ how we can get the HTML version online (we're talking
about several hundred MB) and because of this the default destination
directory may change.
An open task is to make "make doc" work in subsystem directories (e.g.
via "cd /usr/src/sys/doc/subsys && ${MAKE} SUBSYS_TARGET
mumble=${.CURDIR}) as requested in this thread, but I don't expect to
work on this in the next days.
Bye,
Alexander.
--
Selling GoodYear Eagle F1 235/40ZR18, 2x 4mm + 2x 5mm, ~150 EUR
you have to pick it up between Germany/Saarland and Luxembourg/Capellen
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
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 |
|
|
George V. Neville-Neil
*nix forums beginner
Joined: 17 Mar 2006
Posts: 3
|
| Posted: Fri May 26, 2006 11:22 pm Post subject:
Re: doxygen target (was: Re: cvs commit: src Makefile.inc1 ObsoleteFiles.inc src/etc/defaults rc.conf src/etc/mtree BSD.usr.dist src/etc/rc.d Makefile isdnd pcvt syscons src/release/picobsd/build picobsd src/share/man/man4 Makefile atkbd.4 kbdmux.4 pcvt.4
|
|
|
At Fri, 26 May 2006 20:30:03 +0200,
Alexander Leidinger wrote:
| Quote: | I've just committed the framework. Currently it's connected to the
top-level Makefile which generates all HTML docs in OBJDIR. To build
only specific subsystems and/or the PDF docs, you have to go
to /usr/src/sys/doc/subsys and run make (you will see a message with
available targets).
|
Excellent. I'll cvsup and try to play with it.
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 |
|
|
Kirk McKusick
*nix forums beginner
Joined: 19 Mar 2002
Posts: 40
|
| Posted: Mon Jun 05, 2006 5:00 pm Post subject:
Re: Why use `thread' as an argument of Syscalls?
|
|
|
| Quote: | Date: Mon, 5 Jun 2006 11:42:59 -0400 (EDT)
From: Garrett Wollman <wollman@khavrinen.csail.mit.edu
To: rwatson@freebsd.org
Cc: arch@freebsd.org
Subject: Re: Why use `thread' as an argument of Syscalls?
Robert Watson writes:
Certainly consistency. Most system calls do actually use the argument at some
point -- be it to look up a file descriptor, access control, or the like, and
the calling context has it for free and in-hand anyway.
I believe it was the intention of the 4.4BSD developers to completely
eliminate "curproc" (as they had already successfully eliminated "u"),
on the theory that with a modern (RISC) processor architecture,
passing the current process as a parameter wouldn't cost anything
(since it would stay in a register for the life of the system call)
whereas making a context-switched "curproc" would be expensive.
-GAWollman
|
Your above analysis is correct. When we made the pass over the code
base to eliminate all references to "u." we had also hoped to get rid
of all references to "curproc". While we were successful with the former,
it eventually became clear that the latter was not practical. But by
that time, the convention of passing the current process pointer to
Syscall was established, and removing it did not seem to be worth
the effort.
Kirk McKusick
_______________________________________________
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: Mon Jun 05, 2006 5:08 pm Post subject:
Re: Why use `thread' as an argument of Syscalls?
|
|
|
In message <200606051700.k55H0OeJ092393@chez.mckusick.com>, Kirk McKusick write
s:
| Quote: | Your above analysis is correct. When we made the pass over the code
base to eliminate all references to "u." we had also hoped to get rid
of all references to "curproc". While we were successful with the former,
it eventually became clear that the latter was not practical. But by
that time, the convention of passing the current process pointer to
Syscall was established, and removing it did not seem to be worth
the effort.
|
It would be a good Junior Kernel Hacker project to try to replace
these passed arguments with curproc and see if a measurable difference
in performance is obtained.
--
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 |
|
|
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
| Posted: Mon Jun 05, 2006 5:22 pm Post subject:
Re: Why use `thread' as an argument of Syscalls?
|
|
|
On Mon, 5 Jun 2006, Poul-Henning Kamp wrote:
| Quote: | In message <200606051700.k55H0OeJ092393@chez.mckusick.com>, Kirk McKusick write
s:
Your above analysis is correct. When we made the pass over the code base to
eliminate all references to "u." we had also hoped to get rid of all
references to "curproc". While we were successful with the former, it
eventually became clear that the latter was not practical. But by that
time, the convention of passing the current process pointer to Syscall was
established, and removing it did not seem to be worth the effort.
It would be a good Junior Kernel Hacker project to try to replace these
passed arguments with curproc and see if a measurable difference in
performance is obtained.
|
Caution should be applied, however: not all threads passed into functions are
necessarily curthread, nor all processes curproc. It's the obscure edge
places that kill you .
Robert N M Watson
_______________________________________________
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 |
|
|
Attilio Rao
*nix forums beginner
Joined: 26 Feb 2006
Posts: 17
|
| Posted: Mon Jun 05, 2006 5:26 pm Post subject:
Re: Why use `thread' as an argument of Syscalls?
|
|
|
2006/6/5, Poul-Henning Kamp <phk@phk.freebsd.dk>:
| Quote: | It would be a good Junior Kernel Hacker project to try to replace
these passed arguments with curproc and see if a measurable difference
in performance is obtained.
|
There's another thing to consider: having an argument-passing
structure, will improve 'reentrancy' of the kernel.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
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 |
|
|
Jari Aalto
*nix forums beginner
Joined: 08 Feb 2005
Posts: 47
|
| Posted: Tue Jul 04, 2006 6:38 pm Post subject:
Re: Bug#366546: Mail delivery failed: returning message to sender
|
|
|
| > > | I think that this suggestion should go to upstream as well. Having
| > > | nologin in /bin does not make sense only for Debian, of course.
| > > |
|
| FreeBSD-arch AT FreeBSD.org is better for "move x to y" type discussions.
|
| > Tomasz (shadow upstream) mentioned me that nologin lies in /sbin in
| > OpenBSD so that he's tempted to default installing it there.
| >
| > As already mentioned elsewhere, I have no strong opinion on this for
| > what to do in Debian and I'm ready to listen to suggestions and
| > various rationales....
|
| We (FreeBSD) have only recently moved it from /sbin to /usr/sbin; see
| http://marc.theaimsgroup.com/?l=freebsd-current&m=107755834602236&w=2
| for the discussion we had, if it's of any use.
Thanks for the URL.
About the /sbin comment 1: "Bloating of the root filesystem".
I don't see that to be problem here. I think it would be
better to keep things logically separate and resserver /usr
for other things.
About comment 3: There is no reason for nologin( to be in
/sbin, since it isn't needed in single-user mode", this has
weight.
However nologin is a system utility it would be better kept
directly under root directory, if /sbin is not ideal, then
it should go to /bin -- to same place as "login".
Jari
_______________________________________________
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 |
|
|
Ceri Davies
*nix forums addict
Joined: 27 Apr 2003
Posts: 96
|
| Posted: Tue Jul 04, 2006 7:24 pm Post subject:
Re: Bug#366546: Mail delivery failed: returning message to sender
|
|
|
On Tue, Jul 04, 2006 at 09:38:18PM +0300, Jari Aalto+mail.linux wrote:
| Quote: | However nologin is a system utility it would be better kept
directly under root directory, if /sbin is not ideal, then
it should go to /bin -- to same place as "login".
|
That's up to you; we don't consider it a system utility, that's all.
Our hier(7) is pretty clear, and we try to stick to it:
/bin/ user utilities fundamental to both single-user and
multi-user environments
/sbin/ system programs and administration utilities fundamental
to both single-user and multi-user environments
Since it isn't either of the above, it goes under /usr (in FreeBSD; you
are, of course, free to disagree).
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere |
|
| Back to top |
|
|
Christian Perrier
*nix forums Guru Wannabe
Joined: 22 Mar 2005
Posts: 204
|
| Posted: Wed Jul 05, 2006 5:42 am Post subject:
Re: [Pkg-shadow-devel] Bug#374525: Bug#366546: Mail delivery failed: returning message to sender
|
|
|
| Quote: | That's up to you; we don't consider it a system utility, that's all.
Our hier(7) is pretty clear, and we try to stick to it:
/bin/ user utilities fundamental to both single-user and
multi-user environments
/sbin/ system programs and administration utilities fundamental
to both single-user and multi-user environments
|
As a first reaction and as one of the shadow maintainer, I'm now
inclined to agree with the choice of the FreeBSD team here.
The rationale is clear...
I'd like to hear the one from OpenBSD to put nologin in /sbin
though.. they might have a different definition of what goes in /sbin
However, others might have a different point of view in Debian and I'd
like to get all possible advices. I might even consider asking our
Technical Commitee after a discussion in debian-devel (which I don't
put much hope in based on past experience).
In short, let's take a deep breath and think about all this.
The standard we have to comply with in Debian is the FHS 2.3, from the
policy. It states:
/bin : Essential user command binaries (for use by all users)
/bin contains commands that may be used by both the system
administrator and by users, but which are required when no other
filesystems are mounted (e.g. in single user mode). It may also
contain commands which are used indirectly by scripts.
/sbin : System binaries
Utilities used for system administration (and other root-only
commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin
contains binaries essential for booting, restoring, recovering, and/or
repairing the system in addition to the binaries in /bin. [18]
Programs executed after /usr is known to be mounted (when there are no
problems) are generally placed into /usr/sbin. Locally-installed
system administration programs should be placed into
/usr/local/sbin. [19]
The question then shortens down to "will we need nologin when /usr is
not mounted". Do we have existing or future use cases?
PS: let's shorten down the CC list of these mails. My own point here is to
decide what to do in Debian so we might want to stop bothering FreeBSD
developers (which I took the opportunity to sy "hi" to....I have some
good old friends over there). |
|
| Back to top |
|
|
Jari Aalto
*nix forums beginner
Joined: 08 Feb 2005
Posts: 47
|
| Posted: Wed Jul 05, 2006 5:52 am Post subject:
Re: Bug#366546: [Debian] login: please move nologin under /bin directory
|
|
|
| On Tue, Jul 04, 2006 at 09:38:18PM +0300, Jari Aalto+mail.linux wrote:
|
| > However nologin is a system utility it would be better kept
| > directly under root directory, if /sbin is not ideal, then
| > it should go to /bin -- to same place as "login".
|
| That's up to you; we don't consider it a system utility, that's all.
|
| Our hier(7) is pretty clear, and we try to stick to it:
|
| /bin/ user utilities fundamental to both single-user and
| multi-user environments
FHS 2.3 reads
<http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES>
/bin contains commands that may be used by both the system
administrator and by users, but which are required
when no other filesystems are mounted (e.g. in single user mode).
============================================================
| /sbin/ system programs and administration utilities fundamental
| to both single-user and multi-user environments
<http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES>
Utilities used for system administration (and other
root-only commands) are stored in /sbin, /usr/sbin, and
/usr/local/sbin. /sbin contains
binaries essential for booting, restoring, recovering, and/or
====================================================...
repairing the system
| Since it isn't either of the above, it goes under /usr (in FreeBSD; you
| are, of course, free to disagree).
Thank you for explaining.
As Debian follows the FHS, the correct place here seems to be
/bin according to FHS. (as where "login" is also located)
Jari
_______________________________________________
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 |
|
|
Colin Percival
*nix forums addict
Joined: 10 Dec 2004
Posts: 61
|
| Posted: Wed Jul 05, 2006 1:30 pm Post subject:
Re: [Pkg-shadow-devel] Bug#374525: Bug#366546: Mail delivery failed: returning message to sender
|
|
|
Christian Perrier wrote:
| Quote: | As a first reaction and as one of the shadow maintainer, I'm now
inclined to agree with the choice of the FreeBSD team here.
The rationale is clear...
I'd like to hear the one from OpenBSD to put nologin in /sbin
though.. they might have a different definition of what goes in /sbin
|
FWIW, nologin was in /sbin in BSD 4.4; this is almost certainly why
OpenBSD still has /sbin/nologin.
I moved FreeBSD's nologin to /usr/sbin two years ago, because
1. nologin needs to be statically linked to avoid linker environment
security issues,
2. logging attempts to log in to a nologinned account requires that
syslog code be pulled in (which significantly increases the size of
a statically linked binary),
3. we like to keep the root filesystem small, and
4. Since nologin is intended for use in multiuser mode, there's no
reason for it to be on the root filesystem -- in single user mode,
users who aren't supposed to be allowed to login will never get to
the point of running a shell (nologin or otherwise).
In short, under the BSD hierarchy rules, nologin should be in /usr/sbin;
any systems behaving otherwise are doing so for historical reasons only.
Colin Percival
_______________________________________________
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 |
|
|
Ceri Davies
*nix forums addict
Joined: 27 Apr 2003
Posts: 96
|
| Posted: Wed Jul 05, 2006 3:10 pm Post subject:
Re: Bug#366546: [Debian] login: please move nologin under /bin directory
|
|
|
On Wed, Jul 05, 2006 at 08:52:28AM +0300, Jari Aalto+mail.linux wrote:
| Quote: | | On Tue, Jul 04, 2006 at 09:38:18PM +0300, Jari Aalto+mail.linux wrote:
|
| > However nologin is a system utility it would be better kept
| > directly under root directory, if /sbin is not ideal, then
| > it should go to /bin -- to same place as "login".
|
| That's up to you; we don't consider it a system utility, that's all.
|
| Our hier(7) is pretty clear, and we try to stick to it:
|
| /bin/ user utilities fundamental to both single-user and
| multi-user environments
FHS 2.3 reads
http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES
/bin contains commands that may be used by both the system
administrator and by users, but which are required
when no other filesystems are mounted (e.g. in single user mode).
===========================================================
As Debian follows the FHS, the correct place here seems to be
/bin according to FHS. (as where "login" is also located)
|
From my reading, it isn't, since it isn't "required when no other
filesystems are mounted". Obviously, I'm not familiar with your FHS, or
the historical interpretations thereof, though.
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 5:16 am | All times are GMT
|
|
MPAA | Project cars for sale | Buy Anything On eBay | Free Myspace Comments | Loan
|
|
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
