DragonFly BSD
DragonFly kernel List (threaded) for 2003-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Preliminary restructuring layout (was Re: sys/ tree re-structuring proposal)


From: Julian Elischer <julian@xxxxxxxxxxxx>
Date: Wed, 6 Aug 2003 13:21:57 -0700 (PDT)


On Wed, 6 Aug 2003, Matthew Dillon wrote:

> :> ./boot (unchanged)
> :>
> :> ./compile
> :
> :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/scsi
> :
> :> ./dev/disk			Normal disk controllers (incls scsi)
> :> ./dev/disk/ata
> :> ./dev/disk/aha
> :> ./dev/disk/ahb
> :
> :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.


but the scsi adapters are the adapters.. for example..
we use them mostly to talk to scsi scanners etc. here..

We use the Mylex raid controllers to talk to disks and tapes.


> 
>     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..
> :dev/net/ethernet
> :dev/net/wireless
> :dev/net/WAN
> :dev/net/ATM
> :maybe even reverse it to
> :net/dev/ethernet
> 
>     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
>     meta interfaces.  
> 
>     I do separate out ATM because it is a special case.
> 
> :> ./dev/atm			ATM devices
> :
> :dev/net/atm
> 
>     No, just dev/atm.  I don't want to create unnecessarily deep 
>     directory structures.
> 
> :> ./emulation			Syscall/environment emulation (for now)
> :> ./emulation/svr4
> :> ./emulation/svr4/i386
> :
> :
> :how does isdn come under emulation?
> :
> :net/proto/isdn/14b maybe
> 
>     Urk.  i4b doesn't belong in emulation.   I think I will create a 
>     dev/netmf for these meta-interfaces.
> 
> :net/proto/
> 
>     No, just netproto.  Again, no reason to put it in a subdirectory
>     when it is a major part of the kernel.
> 
> :> ./libkern
> :> ./libkern/alpha
> :> ./net
> :> ./netgraph
> :
> :net/proto/inet
> :net/proto/inet6
> 
>     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.
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>
> 




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]