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

Re: sys/ tree re-structuring proposal


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 4 Aug 2003 00:16:58 -0700 (PDT)

:>>sys/modules/
:>>	|
:>>	|- net/      - Network related eg. ethernet drivers, netgraph...
:>>	|- security/ - Things like IPFilter, IPFW and CRYPTO go here...
:>>	|- dev/      - Device Tree (sub-divided by buses)
:>>	|   |
:>>	|   |- pci/	  PCI and related driver build files
:>>	|   |- isa/	  ISA and related build files
:>>	|   |- usb/	  USB and related build files
:>>	|   |- firewire/  IEEE-1394 and related build files
:>>	|   |- etc...
:>>	|
:>>	|- vfs/      - File systems.
:>>	|- exec/     - Emulation and related framework build files
:>>	|- contrib/  - Contributed modules, eg. gnufp, ext2fs, etc.
:>>	|- misc/     - Uncategorized driver build files
:>>
:> 
:> 
:> This was discussed for FreeBSD too, though I'm not sure if it ever hit
:> the lists. Some of the problems that popped up were USB NICs (for
:> instance). Do they belong under net or dev/usb?
:> 
:> There were quite a few examples like that, and perhaps other pitfalls -
:> I wasn't able to stick around until the discussion had settled.
:
:	Ofcourse, the broad category, i.e. the bus is where it goes.
:	So in this case, USB NICs would go under dev/usb.  One might
:	argue about things like multi-bus drivers, in which case a
:	dev/multi category, or something along those lines can be
:	created.
:
:	Cheers.
:
:		-- Hiten (hmp@xxxxxxxx)

    Well, there is a lot of overlap between PCI and ISA but my tendancy
    is to separate out the copies anyway, even if it means a lot of
    duplicate code.  Updating isn't a big deal if you only have two copies
    and, down the road, one of those copies is likely to become obsolete
    (like ISA based multi-port serial cards, for example).

    We need someone to do a comprehensive run through of all the driver code
    to figure out where the gotchas are.

    My suggestion would be to not put it under 'modules' but to have them
    as top level directories under sys/.  I don't see any real need for 
    a 'modules' subdirectory especially if 'most' things eventually wind
    up being 'modules', whatever our definition of a module winds up being.
    Any directory name conflicts can be resolved by renaming as appropriate.

    So, for example, right now we have /usr/src/sys/dev/<random_junk>,
    which we would reorganize into /usr/src/sys/dev/{pci,isa,...}/...

	sys {
	    net
	    security
	    dev {
		pci
		isa
		usb
		firewire
		etc...
	    }
	    vfs
	    exec
	    misc?
	    contrib {
		net
		security
		dev {
		    pci
		    isa
		    usb
		    firewire
		    etc...
		}
		vfs
		exec
		misc?
	    }
	}

    Whatever reorganization we decide on will require some CVS surgery.
    It might be easiest for me to just MV things around in the physical
    cvs tree and just have everyone resync (can cvsup and cvs deal with whole 
    directories being moved around within the repository?).

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>




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