Re: /sys hierarchy
David O'Brien wrote:
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
I would prefer /sys/compile/ARCH as it makes it easier to make a
symlink to another place. Unless of course we get /usr/obj working for
kernel compiles
Huh? All my kernels created with buildkernel are compiled in /usr/obj.
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
jkh _DES: The Book of Bruce has only one sentence in it, and it says
"the actual directives of my cult are left as an exercise for the
reader. Good luck."
EE jkh: does it really include the 'good luck' part?
jkh EE: OK, I made that part up.
jkh EE: I figured it should sound a bit more cheery than how Bruce
initially dictated it to me.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
This must pass through -arch before any implementation. Remember, not
every committer reads current.
John Baldwin wrote:
sys/
${MACHINE}/ - stay mostly the same, the directories under here
mirror the sys/ directories. E.g. MD bootstrap
code would go in the boot/ subdir
boot/ - formerly sys/boot/${MACHINE}
boot/ - just MI boot code now. Depending on portability
of ARC, possibly move boot/arc under
sys/alpha/boot
Don't touch boot. Nothing in the bootstrap is used by the kernel, and
there's just a few kernel files included by the bootstrap (wrongly,
IMHO). It's made by buildworld instead of buildkernel. Ideally, it
should be taken out of sys/ altogether.
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
jkh _DES: The Book of Bruce has only one sentence in it, and it says
"the actual directives of my cult are left as an exercise for the
reader. Good luck."
EE jkh: does it really include the 'good luck' part?
jkh EE: OK, I made that part up.
jkh EE: I figured it should sound a bit more cheery than how Bruce
initially dictated it to me.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 08-Jul-00 Daniel C. Sobral wrote:
This must pass through -arch before any implementation. Remember, not
every committer reads current.
The kernel hackers do since they are running current. :)
John Baldwin wrote:
sys/
${MACHINE}/ - stay mostly the same, the directories under here
mirror the sys/ directories. E.g. MD bootstrap
code would go in the boot/ subdir
boot/ - formerly sys/boot/${MACHINE}
boot/ - just MI boot code now. Depending on portability
of ARC, possibly move boot/arc under
sys/alpha/boot
Don't touch boot. Nothing in the bootstrap is used by the kernel, and
there's just a few kernel files included by the bootstrap (wrongly,
IMHO). It's made by buildworld instead of buildkernel. Ideally, it
should be taken out of sys/ altogether.
I disagree. The bootstrap is not used from userland, but is what
loads the kernel. The kernel uses it to get started in other words.
You don't type /boot/loader after the system is loaded, for example.
--
Daniel C. Sobral (8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sat, 08 Jul 2000 23:32:27 +0900, "Daniel C. Sobral" [EMAIL PROTECTED] said: This must pass through -arch before any implementation. Remember, not every committer reads current. Also remember, not every committer reads arch. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
Greetings all, I have to commend you all on this thread; as mundane as it may have seemed on the outset. It is nice to see that everyone is kind of working together to at the very least consider this proposal, especially now that most of smoke has cleared. I'll admit I'm more of a casual observer in this, but the idea is quite intriguing. Therefore I must ask; would it be worth putting together a sort of RFC regarding this subject and involving the entire BSD community, so that this could be placed on a long term game plan, and properly aligned with other BSD devlopement projects? Something like the new hierarchy shall be this by release such and such, and define some sort of road map to achieve this goal. -- Cheers, Mikel +~+ | Optimized Computer Solutions, Inchttp://www.ocsny.com | 39 W14th Street, Suite 203 212 727 2238 x132 | New York, NY 10011 +~+ begin:vcard n:King;Mikel tel;fax:2124638402 tel;home:http://www.upan.org tel;work:2127272100 x-mozilla-html:TRUE org:Optimized Computer Solutions version:2.1 email;internet:[EMAIL PROTECTED] title:Director of Network Operations Technology adr;quoted-printable:;;39 W14th St.=0D=0ASte 203;New York;NY;10011;US note;quoted-printable:fBSD, PHP, MySql and OCS Rule!!!=0D=0A=0D=0AGoal is to be MS free by the end of 2k. x-mozilla-cpt:;7312 fn:Mikel King end:vcard
Re: /sys hierarchy
I've tried to update the document to reflect the comments I've
received so far:
Current directory structure:
sys/
${MACHINE}/ - MD stuff
conf/ - MD kernel config files
${MACHINE/ - MD code
include/- MD includes
... - various MD modules such as binary compat
boot/ - bootstrap
${MACHINE/ - MI boot code
cam/ - cam subsystem
coda/ - coda fs
compile/ - compile work directory
conf/ - MI kernel config files
contrib/ - 3rd party kernel code
crypto/ - kernel crypto code
ddb/ - DDB
dev/ - several device drivers
fs/ - one file system
gnu/ - GNU kernel code
i4b/ - ISDN support
isa/ - MI ISA base code and a few drivers such as joy0
isofs/- CD9660 fs
kern/ - MI kernel code such as new-bus, vfs, init, etc.
libkern/ - libc for the kernel
miscfs/ - several fs's such as deadfs, devfs, etc.
modules/ - skeleton for the modules
msdosfs/ - MS-DOS FAT fs
net/ - some network drivers such as ppp, slip, bpf, and
generic network interface support
netatalk/ - support for Appletalk network
netatm/ - support for ATM network sockets
netgraph/ - the spiffy netgraph system
netinet/ - IPv4, TCP, UDP
netinet6/ - IPv6, IPsec, TCP and UDP glue
netipx/ - IPX/SPX
netkey/ - undocumented key management protocol - RFC 2367
netnatm/ - native mode ATM
netncp/ - Netware client protocol
netns/- Xerox NS, including IDP and SP
nfs/ - NFS
ntfs/ - NTFS
nwfs/ - Netware FS
pccard/ - PC card drivers
pci/ - MI PCI code and some drivers, notably PCI network
cards
posix4/ - random POSIX code bucket
svr4/ - SVR4 binary compatibility
sys/ - kernel includes
ufs/ - UFS, FFS, and MFS
vm/ - VM system
Here is my proposal, adjusted a little as per suggestions. It attempts to
follow these loose guidelines:
- MD code under sys/${MACHINE_ARCH}
- device drivers (including bus's such as cam and usb) under sys/dev
- file systems under fs/
- networking under net/
sys/
${MACHINE}/ - stay mostly the same, the directories under here
mirror the sys/ directories. E.g. MD bootstrap
code would go in the boot/ subdir
boot/ - formerly sys/boot/${MACHINE}
compat/ - MD code for the binary compatibility layers, would
contain linux, svr4, etc. directories
boot/ - just MI boot code now. Depending on portability
of ARC, possibly move boot/arc under
sys/alpha/boot
compat/ - MI binary compatibility code
linux/ - parts of former sys/i386/linux
svr4/- parts of former sys/svr4
compile/ - move compiling under arch-specific dirs
${MACHINE}/ - formerly sys/compile
conf/ - move NOTES to here from sys/i386/conf, but leave
the rest of the dir the same for now
contrib/ - stay the same. It mirrors the organization of
sys/. For example, contrib'd device drivers under
contrib/sys/dev, which is where they are now.
crypto/ - no change
ddb/ - no change
dev/ - everything in there now plus some extras
cam/- formerly sys/cam
isdn/ - formerly sys/i4b
isa/- formerly sys/isa, this just cintains the support
code for the ISA bus, actual device drivers such as
joy0 would move into sys/dev/mumble
pccard/ - formerly sys/pccard
pci/- formerly sys/pci, split up just as sys/isa
fs/ - everything in there now plus some extras
codafs/ - formerly sys/coda
isofs/ - formerly sys/isofs
msdosfs/- formerly sys/msdosfs
nfs/- formerly sys/nfs
ntfs/ - formerly sys/ntfs
nwfs/ - formerly sys/nwfs
ufs/- formerly sys/ufs/ufs
ffs/- formerly sys/ufs/ffs
mfs/- formerly sys/ufs/mfs
deadfs/ - formerly sys/miscfs/deadfs
devfs/ -
Re: /sys hierarchy
* John Baldwin [EMAIL PROTECTED] [000705 00:04] wrote:
I've tried to update the document to reflect the comments I've
received so far:
Current directory structure:
sys/
${MACHINE}/ - MD stuff
conf/ - MD kernel config files
[gag, snip]
Here is my proposal, adjusted a little as per suggestions. It attempts to
follow these loose guidelines:
- MD code under sys/${MACHINE_ARCH}
- device drivers (including bus's such as cam and usb) under sys/dev
- file systems under fs/
- networking under net/
[snip]
Awesome, so when is this going to be done? :)
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
John Baldwin wrote: Notes: - There has been one vote so far to ditch the whole net/ reorg, although other people have expressed support for it. What do you intend to do with the networking headers? The socket API standards specify the socket related headers and their paths. At least, "net" and "netinet" should not be moved. -Kenjiro To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
Here is my proposal, adjusted a little as per suggestions. It attempts to
follow these loose guidelines:
...
net/ - move existing contents to net/base or something
similar
atalk/ - formerly sys/netatalk
atm/ - formerly sys/netatm
netgraph/- formerly sys/netgraph
ip/ - IPv4, IPv6, and IPsec bits from sys/netinet{,6}
tcp/ - TCP""" "
udp/ - UDP""" "
ipx/ - formerly sys/netipx
key/ - formerly sys/netkey
natm/- formerly sys/netnatm
ncp/ - formerly sys/netncp
ns/ - formerly sus/netns
Notes:
- There has been one vote so far to ditch the whole net/ reorg, although
other people have expressed support for it.
Please take this as another vote to ditch the whole net/ reorg.
It's interesting that as this discussion is going on,the KAME folks are
merging the new IPv6 and IPSEC code into -current and comment that our
network code is much more different that the other BSD's. I'd hate to
see it diverge further unless there's a real compelling reason.
louie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 05-Jul-00 Louis A. Mamakos wrote:
Here is my proposal, adjusted a little as per suggestions. It attempts to
follow these loose guidelines:
...
net/ - move existing contents to net/base or something
similar
atalk/ - formerly sys/netatalk
atm/ - formerly sys/netatm
netgraph/- formerly sys/netgraph
ip/ - IPv4, IPv6, and IPsec bits from sys/netinet{,6}
tcp/ - TCP""" "
udp/ - UDP""" "
ipx/ - formerly sys/netipx
key/ - formerly sys/netkey
natm/- formerly sys/netnatm
ncp/ - formerly sys/netncp
ns/ - formerly sus/netns
Notes:
- There has been one vote so far to ditch the whole net/ reorg, although
other people have expressed support for it.
Please take this as another vote to ditch the whole net/ reorg.
It's interesting that as this discussion is going on,the KAME folks are
merging the new IPv6 and IPSEC code into -current and comment that our
network code is much more different that the other BSD's. I'd hate to
see it diverge further unless there's a real compelling reason.
The KAME integration is a primary reason why I am becoming more
reluctant to reorganize net/, or possibly postpone it until that work
is done. Another guideline that lines up with our existing code might
be to require all networking modules to use a directory matching
the regex 'net.*'. I'm planning on doing this in stages anyway, and
net/ would probably be the last stage if it is done, but I need to
discuss this with Peter first. :)
louie
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 05-Jul-00 Kenjiro Cho wrote: John Baldwin wrote: Notes: - There has been one vote so far to ditch the whole net/ reorg, although other people have expressed support for it. What do you intend to do with the networking headers? The socket API standards specify the socket related headers and their paths. At least, "net" and "netinet" should not be moved. The headers will always be installed in the right place in /usr/include: Makefile's are editable. As far as kernel compiles, symlinks can be created in the work directory as one possible solution. For example, sys/compile/i386/GENERIC/netinet - ../../../../net/inet. This would most likely result in netinet _not_ being split up. -Kenjiro -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Wed, 5 Jul 2000, John Baldwin wrote: The headers will always be installed in the right place in /usr/include: Makefile's are editable. As far as kernel compiles, symlinks can be created in the work directory as one possible solution. For example, sys/compile/i386/GENERIC/netinet - ../../../../net/inet. This would most likely result in netinet _not_ being split up. As much as I'd love a complete cleanup of sys/, this cure seems to be worse than the problem. :-) Take this as another vote to leave net/ as is, if only to keep the includes in kernel code in sync with includes in userland code :-). Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Tue, Jul 04, 2000 at 03:53:12PM -0700, Marcel Moolenaar wrote: Good point. For the linuxulator this has been discussed before and something in the line off... ...came out of it. Even before you get an Alpha, would you be able to seperate the Linux bits before 4.1-R so the 4.x sys/ tree stays the same for most of its life and matches 5-CURRENT? I have a tarball of /sys/alpha/linux/ that I could pass on to you to look at what is needed MD wise for the Alpha. Just a list of what should be repo copied to /sys/linux and ``cvs rm'' from /sys/i386/linux/ would be very helpful. I can do forward the list to the CVS meisers and do the cleanup if you don't have time to deal with it. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
David O'Brien wrote: On Tue, Jul 04, 2000 at 03:53:12PM -0700, Marcel Moolenaar wrote: Good point. For the linuxulator this has been discussed before and something in the line off... ...came out of it. Even before you get an Alpha, would you be able to seperate the Linux bits before 4.1-R so the 4.x sys/ tree stays the same for most of its life and matches 5-CURRENT? I have a tarball of /sys/alpha/linux/ that I could pass on to you to look at what is needed MD wise for the Alpha. Tricky. I have been working on this before and the approach I took (and seemed most likely to succeed) was to look at each syscall and see if it was directly or indirectly MD or MI. I could do this before I have an Alpha assuming that we don't need a working Alpha port yet. The question is if we have enough time for it? On the other hand, it doesn't have to be perfect, as long as the i386 port works... I should have the tarball somewhere as well (at least the one Andrew made "public"). Send me what you've got (to make sure I have the latest) and I'll take a look at it... -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Wed, Jul 05, 2000 at 12:47:06PM -0700, Marcel Moolenaar wrote: I could do this before I have an Alpha assuming that we don't need a working Alpha port yet. The question is if we have enough time for it? On the other hand, it doesn't have to be perfect, as long as the i386 port works... Yes on the i386, and IMHO yes on the Alpha issue. I should have the tarball somewhere as well (at least the one Andrew made "public"). Send me what you've got (to make sure I have the latest) and I'll take a look at it... I started with Andrews and made some tweaks. It used to build fine, but a month ago got broke with some changes to i386/linux. I'll try to get it buildable again before sending it on. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Wed, 5 Jul 2000, John Baldwin wrote:
Here is my proposal, adjusted a little as per suggestions. It attempts to
follow these loose guidelines:
- MD code under sys/${MACHINE_ARCH}
- device drivers (including bus's such as cam and usb) under sys/dev
- file systems under fs/
- networking under net/
I would like also suggest a directory for optional kernel
interfaces which doesn't belong to drivers (syscall and sysctl extensions
for example) and can't go under sys/dev/. They can be considered as
'kernel libraries' and may live under sys/lib directory (it should be
organized as sys/dev, eg. one directory per interface).
Comments ?
--
Boris Popov
http://www.butya.kz/~bp/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
Boris Popov wrote:
On Wed, 5 Jul 2000, John Baldwin wrote:
Here is my proposal, adjusted a little as per suggestions. It attempts to
follow these loose guidelines:
- MD code under sys/${MACHINE_ARCH}
- device drivers (including bus's such as cam and usb) under sys/dev
- file systems under fs/
- networking under net/
I would like also suggest a directory for optional kernel
interfaces which doesn't belong to drivers (syscall and sysctl extensions
for example) and can't go under sys/dev/. They can be considered as
'kernel libraries' and may live under sys/lib directory (it should be
organized as sys/dev, eg. one directory per interface).
Comments ?
OpenBSD has a precedent for this with sys/lib containing libkern, libz,
and some other library. Boris has a libiconv that he needs to import
for
Netware stuff if I'm correct. If we deem that it needs to go in the
kernel,
then I can add sys/lib to the list.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
In message [EMAIL PROTECTED] Robert Watson writes: : On Wed, 5 Jul 2000, John Baldwin wrote: : : The headers will always be installed in the right place in : /usr/include: Makefile's are editable. As far as kernel : compiles, symlinks can be created in the work directory as : one possible solution. For example, : sys/compile/i386/GENERIC/netinet - ../../../../net/inet. : This would most likely result in netinet _not_ being split : up. : : As much as I'd love a complete cleanup of sys/, this cure seems to be : worse than the problem. :-) Take this as another vote to leave net/ as : is, if only to keep the includes in kernel code in sync with includes in : userland code :-). The proposed change also breaks the ability to have /usr/include/* be symbolic links to your real source tree. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 06-Jul-00 Warner Losh wrote: In message [EMAIL PROTECTED] John Baldwin writes: : pccard/ - formerly sys/pccard Maintainers Veto. Do not do this. This sys/pccard will go away in time. There will be a sys/dev/pccard when newcard comes in. DO NOT MOVE sys/pccard. It will make it impossible to have both OLDCARD and NEWCARD in the tree at the same time. Leave it be as a bit of cruft that will be (and is being) replaced. Thank you for your understanding in this matter :-). No problem. : - There has been one vote so far to ditch the whole net/ reorg, although : other people have expressed support for it. Make that two votes. It is a gratuitous change that will buy us only incompatibility with other systems. Also, it will make installing header files into /usr/include/netinet much harder than it needs to be. And these are the defined APIs that we can't break. Please keep that in mind :-) It's pretty much dead at this point. : - There have been a few votes for sys/bus instead of sys/dev for isa, eisa, : pci, cam, usb, and friends. Don't care too much. Will make compatibility harder with other systems, but not hugely so. I'm going with sys/dev since that is where they are in both OpenBSD and NetBSD. : - The question has been raised as to whether or not splitting up netinet : is feasible. I'd like to hear back some more from people working with : the code if splitting it up is difficult, and if it is, if having : sys/net/inet containing all IP, TCP, UDP, etc. is a more workable option? No. I don't think it is. It's not relevant if it isn't going to be moved. Warner -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Wed, 5 Jul 2000, John Baldwin wrote: I would like also suggest a directory for optional kernel interfaces which doesn't belong to drivers (syscall and sysctl extensions for example) and can't go under sys/dev/. They can be considered as 'kernel libraries' and may live under sys/lib directory (it should be organized as sys/dev, eg. one directory per interface). Comments ? OpenBSD has a precedent for this with sys/lib containing libkern, libz, and some other library. Boris has a libiconv that he needs to import for Netware stuff if I'm correct. If we deem that it needs to go in the kernel, then I can add sys/lib to the list. It will be shared by both smbfs and nwfs. One also can convert msdosfs to use it too. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, 2 Jul 2000, Chris Costello wrote:
On Sunday, July 02, 2000, Rodney W. Grimes wrote:
Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src. IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.
It does already, but how do you propose the user build and
install the kernel? ``cd /usr/obj ...'' is inconsistent with any
current procedures.
`cd /sys/${MACHINE}/conf; make FOO' should make configuration FOO.
(For the current build scheme to work, there would have to be a
subdirectory of /sys/${MACHINE}/conf for each configuration file.
I don't like the tiny directories required for this.)
${MACHINE_ARCH} would be wrong here. pc98 != i386.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
David O'Brien wrote: They should be stated because they need to be moved linux - Linux binary compat Also buses isa - there is some MI stuff in here Good point. For the linuxulator this has been discussed before and something in the line off... sys/$MACHINE/compat/linux // MD part sys/$MACHINE/compat/others sys/compat/linux// MI part sys/compat/others ...came out of it. This also matches where the Linuxulator has its sysctl variables (= compat.linux.*) and where other emulators are expected to have their variables. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, 02 Jul 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] "David O'Brien" writes:
: On Sun, Jul 02, 2000 at 01:31:28PM -0600, Warner Losh wrote:
: : cd blah is currently
: : cd ../../compile/${KERNNAME}
: : it becomes
: : cd /usr/obj/`pwd`/${KERNNAME}
:
: My take on this is that it would make it slightly harder to develop
: kernel stuff in the tree. I don't like that prospect, and I think
:
: I agree that it is nicer to make the created headers, Makefile, etc. into
: /sys/compile/ , BUT it would be better to put the .o's in /usr/obj/ to
: seperate the generated binary from the [generated] source.
Having the ability to do this is great (like I said for the typical
buildworld case). Having the ability to turn it off is also desirable
to aid in normal development. Even /usr/obj can be turned off for the
normal case by setting MAKEOBJDIRPREFIX to /bogus (assuming you have
no /bogus). So too should any new feature like this be.
config
shouldn't be modified to put things in /usr/obj/`pwd`${KERNNAME}, but
instead one should use the -d feature of config in the buildkernel
target to put this into /usr/obj.
Or "config" could be rewritten to act like NORMAL unix tools and leave its
output in the directory where it is executed. IMHO, the "-d" is the backwards
way to do things. I objected when it was written, but the author insisted
that "compatability" was more important than correct design.
Write a new version under a different name and create a shell "wrapped" for
those who refuse progress.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 02-Jul-00 Garrett Wollman wrote: On Sun, 02 Jul 2000 10:44:23 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: encapsulation. Of course, someone more familiar with the actual code in the tree might provide some better insight on the feasibility of splitting these up. Don't, or else legions of network people will curse you to the end of your days. So would you prefer sys/net/inet containing all of TCP, UDP, IP, etc.? -GAWollman -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 01-Jul-00 Jordan K. Hubbard wrote:
Yes he did. Talk to various committers and you'll see that many have
ideas where files should live. There have been long threads on this
issue that got nowhere. The reason things are in such a messy state is
when something new is brought in, or is changed suffiently much for a
repo copy the person take the chance to put the files where *they* think
they should live. Vs. where there would be consistency in the /sys tree.
Talking to "various committers" will only yield various opinions and
end up leading nowhere, however. Perhaps if someone were to take
it upon themselves to post a detailed proposal of where things should
be moved to, others could at least comment more authoritatively
(and substantially) on the topic rather than just engaging in more
vague hand-waving.
I feel masochistic at the moment, so here's a suggestion. Feel free
to rip it all up to pieces, ya'll. And to start off: I like green
bikesheds. (I.e. let's settle on something sensible and not get
_too_ involved, please, or just shoot the whole idea down and enjoy
our sphaghetti)
Current directory structure:
sys/
${MACHINE_ARCH}/ - MD stuff
conf/ - MD kernel config files
${MACHINE_ARCH}/- MD code
include/- MD includes
... - various MD modules such as binary compat
boot/ - bootstrap
${MACHINE_ARCH}/- MI boot code
cam/ - cam subsystem
coda/ - coda fs
compile/ - compile work directory
conf/ - MI kernel config files
contrib/ - 3rd party kernel code
crypto/ - kernel crypto code
ddb/ - DDB
dev/ - several device drivers
fs/ - one file system
gnu/ - GNU kernel code
i4b/ - ISDN support
isa/ - MI ISA base code and a few drivers such as joy0
isofs/- CD9660 fs
kern/ - MI kernel code such as new-bus, vfs, init, etc.
libkern/ - libc for the kernel
miscfs/ - several fs's such as deadfs, devfs, etc.
modules/ - skeleton for the modules
msdosfs/ - MS-DOS FAT fs
net/ - some network drivers such as ppp, slip, bpf, and
generic network interface support
netatalk/ - support for Appletalk network
netatm/ - support for ATM network sockets
netgraph/ - the spiffy netgraph system
netinet/ - IPv4, TCP, UDP
netinet6/ - IPv6, IPsec, TCP and UDP glue
netipx/ - IPX/SPX
netkey/ - undocumented key management protocol - RFC 2367
netnatm/ - native mode ATM
netncp/ - Netware client protocol
netns/- Xerox NS, including IDP and SP
nfs/ - NFS
ntfs/ - NTFS
nwfs/ - Netware FS
pccard/ - PC card drivers
pci/ - MI PCI code and some drivers, notably PCI network cards
posix4/ - random POSIX code bucket
svr4/ - SVR4 binary compatibility
sys/ - kernel includes
ufs/ - UFS, FFS, and MFS
vm/ - VM system
Ok (/me dons the asbestos suit, climbs into the concrete room and locks
the door.) Here is my proposal. It attempts to follow these loose guidelines:
- MD code under sys/${MACHINE_ARCH}
- device drivers (including bus's such as cam and usb) under sys/dev
- file systems under fs/
- networking under net/
sys/
${MACHINE_ARCH} - stay the same, except add boot/ subdir
boot/ - formerly sys/boot/${MACHINE_ARCH}
boot - just MI boot code now. Depending on portability
of ARC, possibly move boot/arc under
sys/alpha/boot
compile/ - no change
conf/ - move NOTES to here from sys/i386/conf, but leave
it the same for now
contrib/ - stay the same. It mirrors the organization of
sys/. For example, contrib'd device drivers under
contrib/sys/dev, which is where they are now.
crypto/ - no change
ddb/ - no change
dev/ - everything in there now plus some extras
cam/- formerly sys/cam
i4b/- formerly sys/i4b
isa/- formerly sys/isa, this just cintains the support
code for the ISA bus, actual device drivers such as
joy0 would move into sys/dev/mumble
pccard/ - formerly sys/pccard
pci/- formerly sys/pci, split up just as sys/isa
fs/ -
Re: /sys hierarchy
On Sunday, July 02, 2000, John Baldwin wrote:
ip/ - IPv4, IPv6, and IPsec bits from sys/netinet{,6}
tcp/ - TCP""" "
udp/ - UDP""" "
Can this really be separated to such a degree? Since TCP and
UDP are inet protocols, do they _need_ to be separated this way?
--
|Chris Costello [EMAIL PROTECTED]
|You can't make a program without broken egos.
`-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, Jul 02, 2000 at 12:36:59AM -0700, John Baldwin wrote:
Ok (/me dons the asbestos suit, climbs into the concrete room and locks
the door.) Here is my proposal. It attempts to follow these loose guidelines:
compile/ - no change
I'd change this into compile/${MACHINE_ARCH} so that a single shared source
tree can be used to build [alpha,i386] kernels. In the current setup one
gets clashes with GENERIC etc.
--
Wilko Bulte http://www.freebsd.org "Do, or do not. There is no try"
[EMAIL PROTECTED] http://www.nlfug.nl Yoda - The Empire Strikes Back
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 02-Jul-00 Wilko Bulte wrote:
On Sun, Jul 02, 2000 at 12:36:59AM -0700, John Baldwin wrote:
Ok (/me dons the asbestos suit, climbs into the concrete room and locks
the door.) Here is my proposal. It attempts to follow these loose guidelines:
compile/ - no change
I'd change this into compile/${MACHINE_ARCH} so that a single shared source
tree can be used to build [alpha,i386] kernels. In the current setup one
gets clashes with GENERIC etc.
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 02-Jul-00 Chris Costello wrote:
On Sunday, July 02, 2000, John Baldwin wrote:
ip/ - IPv4, IPv6, and IPsec bits from sys/netinet{,6}
tcp/ - TCP""" "
udp/ - UDP""" "
Can this really be separated to such a degree? Since TCP and
UDP are inet protocols, do they _need_ to be separated this way?
A directory listing of sys/netinet shows many in_* files, ip_* files,
tcp_* files, and udp_* files. Note that TCP and UDP aren't explicity
tied to IP, they are simply wrapped inside of an IP packet. In theory
you can run TCP over IPX for example by using the same method of
encapsulation. Of course, someone more familiar with the actual code
in the tree might provide some better insight on the feasibility of
splitting these up.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sunday, July 02, 2000, John Baldwin wrote:
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
I think that compile/${MACHINE_ARCH} is the proper way to do
this. Everything else is source only, all the object files end
up inside compile/ so there's only one place to clean up.
--
|Chris Costello [EMAIL PROTECTED]
|My reality check just bounced.
`--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On 02-Jul-00 Chris Costello wrote:
On Sunday, July 02, 2000, John Baldwin wrote:
ip/ - IPv4, IPv6, and IPsec bits from sys/netinet{,6}
tcp/ - TCP""" "
udp/ - UDP""" "
Can this really be separated to such a degree? Since TCP and
UDP are inet protocols, do they _need_ to be separated this way?
A directory listing of sys/netinet shows many in_* files, ip_* files,
tcp_* files, and udp_* files. Note that TCP and UDP aren't explicity
tied to IP, they are simply wrapped inside of an IP packet. In theory
you can run TCP over IPX for example by using the same method of
encapsulation. Of course, someone more familiar with the actual code
in the tree might provide some better insight on the feasibility of
splitting these up.
Well, in theory maybe, but note that the TCP checksum is computed
over a the TCP header and a pseudo header composed of the IPv4 transport
addresses. The layering of the protocols is a fine intellectual
notion, but don't confuse the layering with an efficient implementation.
louie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sunday, July 02, 2000, John Baldwin wrote:
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
I think that compile/${MACHINE_ARCH} is the proper way to do
this. Everything else is source only, all the object files end
up inside compile/ so there's only one place to clean up.
Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src. IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sunday, July 02, 2000, Rodney W. Grimes wrote:
Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src. IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.
It does already, but how do you propose the user build and
install the kernel? ``cd /usr/obj ...'' is inconsistent with any
current procedures.
--
|Chris Costello [EMAIL PROTECTED]
|If a program is useless, it must be documented.
`---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, Jul 02, 2000 at 11:06:58AM -0700, Rodney W. Grimes wrote:
On Sunday, July 02, 2000, John Baldwin wrote:
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
I think that compile/${MACHINE_ARCH} is the proper way to do
this. Everything else is source only, all the object files end
up inside compile/ so there's only one place to clean up.
Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src. IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.
Yes, this is definitely the cleanest solution IMO.
--
Wilko Bulte http://www.freebsd.org "Do, or do not. There is no try"
[EMAIL PROTECTED] http://www.nlfug.nl Yoda - The Empire Strikes Back
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
...
I feel masochistic at the moment, so here's a suggestion. Feel free
to rip it all up to pieces, ya'll. And to start off: I like green
bikesheds. (I.e. let's settle on something sensible and not get
I prefer blue ones :-)
...
Ok (/me dons the asbestos suit, climbs into the concrete room and locks
the door.) Here is my proposal. It attempts to follow these loose guidelines:
Let me go hunting for flame thrower and concrete saw :-)
- MD code under sys/${MACHINE_ARCH}
- device drivers (including bus's such as cam and usb) under sys/dev
Perhaps, sys/bus and sys/dev, instead of lumping it all into one
sys/dev.
- networking under net/
That one is going to be a really really hard one over the longrun,
it is going to make the source code incompatible with every other
BSD based source tree requireing path mangling anytime something
is brought in from some place else. Especially look at what
this would do to the /usr/include/net* hierarchy and how that
effects userland code. Take a look at how many man pages this
would impact (to get an idea do ``cd /usr/share/man/man3;
zgrep netinet *''.)
sys/
...
net/ - move existing contents to net/base or something similar
...
atm/ - formerly sys/netatm
natm/- formerly sys/netatm
Ooopsss... natm/ should go away, you already have a better place for that :-)
ncp/ - formerly sys/netncp
ns/ - formerly sus/netns
^
We have no sus directory :-)
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sunday, July 02, 2000, Rodney W. Grimes wrote:
Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src. IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.
It does already, but how do you propose the user build and
install the kernel? ``cd /usr/obj ...'' is inconsistent with any
current procedures.
Just the argument to the cd has changed, the command sequence is
still:
cd blah
make depend make make install.
cd blah is currently
cd ../../compile/${KERNNAME}
it becomes
cd /usr/obj/`pwd`/${KERNNAME}
config(8) will need to produce a better makefile using `pwd` to
figure out the path to the kernel sources. BDE probably has lots
of tips about how to do this.
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, 02 Jul 2000 10:44:23 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: encapsulation. Of course, someone more familiar with the actual code in the tree might provide some better insight on the feasibility of splitting these up. Don't, or else legions of network people will curse you to the end of your days. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
In message [EMAIL PROTECTED] "Rodney W. Grimes" writes:
: Just the argument to the cd has changed, the command sequence is
: still:
: cd blah
: make depend make make install.
:
: cd blah is currently
: cd ../../compile/${KERNNAME}
: it becomes
: cd /usr/obj/`pwd`/${KERNNAME}
:
: config(8) will need to produce a better makefile using `pwd` to
: figure out the path to the kernel sources. BDE probably has lots
: of tips about how to do this.
My take on this is that it would make it slightly harder to develop
kernel stuff in the tree. I don't like that prospect, and I think
this would impose some hardship on third parties that are using
FreeBSD. If it could be turned off, that would be ideal. It ties the
userland and kernel together too tightly, imho.
For the average buildworld, it might not be bad, however.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
"Rodney W. Grimes" wrote:
On Sunday, July 02, 2000, Rodney W. Grimes wrote:
Actually the whole src/sys/compile thing should go away, it is
one of the last things that has to be dealt with for a totally
read-only mounted /usr/src. IMHO it should be moved to /usr/obj,
and /usr/obj should, if it hasn't already, be enhanced to include
a ${MACHINE_ARCH} component.
It does already, but how do you propose the user build and
install the kernel? ``cd /usr/obj ...'' is inconsistent with any
current procedures.
Just the argument to the cd has changed, the command sequence is
still:
cd blah
make depend make make install.
If we're going to do this (and I'm all for anything that improves the
read-onliness of /usr/src) I suggest that we can hide all of the pain of
changing the process behind popularizing the buildkernel and
installkernel targets. Thus, when someone wants to paint the bikeshed
yellow in a few years the users won't have to be re-re-educated.
Doug
--
"Live free or die"
- State motto of my ancestral homeland, New Hampshire
Do YOU Yahoo!?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, Jul 02, 2000 at 12:36:59AM -0700, John Baldwin wrote:
Current directory structure:
sys/
${MACHINE_ARCH}/ - MD stuff
conf/ - MD kernel config files
${MACHINE_ARCH}/- MD code
include/- MD includes
... - various MD modules such as binary compat
They should be stated because they need to be moved
linux - Linux binary compat
Also buses
isa - there is some MI stuff in here
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, Jul 02, 2000 at 10:44:22AM -0700, John Baldwin wrote:
compile/ - no change
I'd change this into compile/${MACHINE_ARCH} so that a single shared source
tree can be used to build [alpha,i386] kernels. In the current setup one
gets clashes with GENERIC etc.
AS much as I hate this idea, I have to support it strongly.
Sounds good to me actually. Although, should it be ${MACHINE_ARCH}/compile
instead in keeping with the mentioned goal of keeping all MD stuff under
${MACHINE_ARCH}?
I would prefer /sys/compile/ARCH as it makes it easier to make a
symlink to another place. Unless of course we get /usr/obj working for
kernel compiles
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sun, Jul 02, 2000 at 01:31:28PM -0600, Warner Losh wrote:
: cd blah is currently
: cd ../../compile/${KERNNAME}
: it becomes
: cd /usr/obj/`pwd`/${KERNNAME}
My take on this is that it would make it slightly harder to develop
kernel stuff in the tree. I don't like that prospect, and I think
I agree that it is nicer to make the created headers, Makefile, etc. into
/sys/compile/ , BUT it would be better to put the .o's in /usr/obj/ to
seperate the generated binary from the [generated] source.
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
In message [EMAIL PROTECTED] "David O'Brien" writes:
: On Sun, Jul 02, 2000 at 01:31:28PM -0600, Warner Losh wrote:
: : cd blah is currently
: : cd ../../compile/${KERNNAME}
: : it becomes
: : cd /usr/obj/`pwd`/${KERNNAME}
:
: My take on this is that it would make it slightly harder to develop
: kernel stuff in the tree. I don't like that prospect, and I think
:
: I agree that it is nicer to make the created headers, Makefile, etc. into
: /sys/compile/ , BUT it would be better to put the .o's in /usr/obj/ to
: seperate the generated binary from the [generated] source.
Having the ability to do this is great (like I said for the typical
buildworld case). Having the ability to turn it off is also desirable
to aid in normal development. Even /usr/obj can be turned off for the
normal case by setting MAKEOBJDIRPREFIX to /bogus (assuming you have
no /bogus). So too should any new feature like this be. config
shouldn't be modified to put things in /usr/obj/`pwd`${KERNNAME}, but
instead one should use the -d feature of config in the buildkernel
target to put this into /usr/obj.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sat, Jul 01, 2000 at 06:12:51PM +0400, Ilmar S. Habibulin wrote: Can somebody move thing around in sys? I mean put all fs code under let say '/sys/fs' subdir. And all network protocols code under /sys/net (or netproto)? Why? Because you like it better? Or to confuse the h*ck out of people who are used to the current tree? -- Wilko Bulte http://www.freebsd.org "Do, or do not. There is no try" [EMAIL PROTECTED] http://www.nlfug.nl Yoda - The Empire Strikes Back To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sat, 1 Jul 2000, Wilko Bulte wrote: Can somebody move thing around in sys? I mean put all fs code under let say '/sys/fs' subdir. And all network protocols code under /sys/net (or netproto)? Why? Because you like it better? Or to confuse the h*ck out of people who are used to the current tree? I think that it would be better because kernel become be better structured that way. Now we have more that 40 subdirs in /sys, 4 fs subdirs (isofs, fs, miscfs, ufs), 3 standalone fs dirs (msdosfs, ntfs and nwfs). isofs and fs subdirs are containing only one entry each. So why not to merge all this code under one subdir /sys/fs? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sat, 1 Jul 2000, Garrett Wollman wrote: Can somebody move thing around in sys? I mean put all fs code under let say '/sys/fs' subdir. And all network protocols code under /sys/net (or netproto)? Why? What benefit would that have? Some order, i suppose. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sat, Jul 01, 2000 at 07:14:35PM +0400, Ilmar S. Habibulin wrote: Some order, i suppose. There is plenty of order in the current system. Garrett Wollman suggested that you answer this question carefully, and you have not done that, but provide a vague summary of your beliefs. Moreover, many people are used to the current system; changing it is a fundamental, non-trivial job. This requires good reasoning. -- Will Andrews [EMAIL PROTECTED] [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
On Sat, Jul 01, 2000 at 01:26:17PM -0400, Will Andrews wrote: On Sat, Jul 01, 2000 at 07:14:35PM +0400, Ilmar S. Habibulin wrote: Some order, i suppose. There is plenty of order in the current system. Feh. Garrett Wollman suggested that you answer this question carefully, and you have not done that, but provide a vague summary of your beliefs. Yes he did. Talk to various committers and you'll see that many have ideas where files should live. There have been long threads on this issue that got nowhere. The reason things are in such a messy state is when something new is brought in, or is changed suffiently much for a repo copy the person take the chance to put the files where *they* think they should live. Vs. where there would be consistency in the /sys tree. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
In message [EMAIL PROTECTED], "David O'Brien" writes: On Sat, Jul 01, 2000 at 01:26:17PM -0400, Will Andrews wrote: On Sat, Jul 01, 2000 at 07:14:35PM +0400, Ilmar S. Habibulin wrote: Some order, i suppose. There is plenty of order in the current system. Feh. Garrett Wollman suggested that you answer this question carefully, and you have not done that, but provide a vague summary of your beliefs. Yes he did. Talk to various committers and you'll see that many have ideas where files should live. There have been long threads on this issue that got nowhere. The reason things are in such a messy state is when something new is brought in, or is changed suffiently much for a repo copy the person take the chance to put the files where *they* think they should live. Vs. where there would be consistency in the /sys tree. In fact, I belive there actually was a consensus for moving filesystems under /sys/fs but not for moving net*. The reason for the difference in concensus is probably that net* is a systematic prefix. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
Yes he did. Talk to various committers and you'll see that many have ideas where files should live. There have been long threads on this issue that got nowhere. The reason things are in such a messy state is when something new is brought in, or is changed suffiently much for a repo copy the person take the chance to put the files where *they* think they should live. Vs. where there would be consistency in the /sys tree. Talking to "various committers" will only yield various opinions and end up leading nowhere, however. Perhaps if someone were to take it upon themselves to post a detailed proposal of where things should be moved to, others could at least comment more authoritatively (and substantially) on the topic rather than just engaging in more vague hand-waving. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
