DragonFly kernel List (threaded) for 2003-08
Re: Preliminary restructuring layout (was Re: sys/ tree re-structuring proposal)
:> ./boot (unchanged)
:I prefer -current's [arch]/compile
I didn't mess with ./compile. We'll set it aside and do a second
cvs reorg pass to deal with it.
:I think raid adapters SHOULD be under 'disk'
:dev/disk/raid woudl be fine, except note that (for example) teh mly driver
:exports its virtual disks via the CAM system.. so maybe it should be inder
:> ./dev/disk Normal disk controllers (incls scsi)
:I think scsi adapters should not be under disk..
:maybe dev/scsi, but maybe as a bus as they are logically similar to USB etc.
Hmm. Well, our SCSI abstraction is CAM and that is in bus. With the
cam abstraction the scsi drivers themselves are pretty much relegated
to being devices that are not much different then, say, IDE. People
tend to associate SCSI with disks so that's where I've put them.
I consider RAID to be a special case. There are enough raid drivers
to warrent their own directory and, again, people almost universally
differentiate between straight scsi and hardware raid subsystems.
I suppose we could come up with a directory name other then 'disk'
to cover these guys but I can't think of a good name that people will
immediately associate with a scsi driver other then 'disk'.
:> ./dev/netif Network Interfaces
:I'd even break them further..
:maybe even reverse it to
Hmm. Well, I think splitting things up by the type of network link
(wireless vs ethernet) is a bit silly since most people treat the
interfaces the same, but we do have rather a mess in net/ which
contains meta-drivers like TAP, TUN, and FAITH, with no good
place to put them. Maybe we need a dev/netmf directory for the
I do separate out ATM because it is a special case.
:> ./dev/atm ATM devices
No, just dev/atm. I don't want to create unnecessarily deep
:> ./emulation Syscall/environment emulation (for now)
:how does isdn come under emulation?
Urk. i4b doesn't belong in emulation. I think I will create a
dev/netmf for these meta-interfaces.
No, just netproto. Again, no reason to put it in a subdirectory
when it is a major part of the kernel.
Eventually we will have to clean up netinet and turn things like
TCP and IP into real netproto's. I can't do that in this stage, maybe
as another stage once all the work from this one settles down.