cowloop technology

Matthew Dillon dillon at apollo.backplane.com
Thu Jan 19 11:48:21 PST 2006


:I'm more concerned about the concept than the perfomance. Im against
:the automatic creation and removal of files in /dev. Im sure the
:problems devfs tries to address is solvable in a much cleaner
:solution.
:
:If Im not mistaken there was a similar thread here at these lists a
:year ago where Matt stated his own ideas for major / minor removal
:etc.
:
:-Jonas

    There are a bunch of ways that /dev can be cleaned up, but it isn't
    really a priority because while the current dev methodology is 
    sometimes inconvenient it still works just fine.

    One method that would work would be to have a specially tagged directory
    and then have the system parse device names in that directory.  So
    instead of having to create 37 /dev/ad0* files we would only have to 
    create one "/dev/ad0" and lookups of things like "/dev/ad0s1h" would
    automatically be converted to "/dev/ad" with the "0s1h" part parsed
    out and passed to the device code for further interpretation.

    Instead of having major/minor numbers, the devices would be looked up
    by name.  so e.g. /dev/ad would locate ANY "ad" device.  

    One could even theoretically do away with the contents of /dev entirely
    and simply parse the entire file name as a device.  So one would then
    only need a specially tagged, empty /dev directory and all accesses within
    that directory would be parsed as devices.  We could also allow specific
    devices needing different permissions to be specified, such as 
    "/dev/ad0s1h", and "dev/ad" would still deal with all the loose ends.

    The directory tagging could be implemented outside the filesystem
    code using nullfs or something similar.

    I do feel that it is important that devices still be integrated into
    the filesystem namespace in some manner so permissions and ownership
    can still be assigned, access and modification times updated, and so
    forth.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Kernel mailing list