Re: [linux-usb] Re: USB device allocation

Scott Henry (scotth@sgi.com)
08 Oct 1999 18:57:25 -0700


>>>>> "R" == Richard B Johnson <root@chaos.analogic.com> writes:

R> On Fri, 8 Oct 1999, Khimenko Victor wrote:
>>
>> Devfs DO NOT need major/minor system. It uses major/minor system for existing
>> devices to simplify conversation but it's not requirement.

R> What? The only reason for any of the stuff in the /dev directory is
R> to associate a major/minor number with a file-descriptor. This happens
R> during open(). This is Unix and that's the way Unix works. the choice
R> of putting such "devices" in the "/dev" directory is policy. They
R> could be anywhere.

major/minor is a hack to workaround /dev being on a regular
filesystem. major/minor is just a lookup table to translate opening
a file into associating some device+state with a file descriptor.

That's ALL majors and minors are -- indirection. lookup. a
workaround. a hack. Just because it is traditional doesn't mean that
it isn't a kludge.

devfs (and equivalents) directly associate the device file with the
driver, avoiding the need for the indirect lookup. And, therefore,
the need for major/minor numbers (major numbers at least). Because
they are in memory, the incore inode has a spot for
filesystem-specific data. This would include a driver entrypoint
plus some driver-specific data (equivalent to the minor number,
which has always been driver-specific). It probably _is_ the minor
number for compatibility and ease of porting, though it would often
be more efficient if it were not, but something more specific to the
device.

Now I should look at the devfs source to see if he did it that way...

Note that, for at least this implementation of a devfs, we are
exchanging one well-known and traditional workaround (major/minor
numbers), for a new and unfamiliar one (non-persistence of
non-default permissions/ownership).

-- 
 Scott Henry <scotth@sgi.com> /  Help! My disclaimer is missing!
 IRIX MTS,                   /  GIGO *really* means: Garbage in, Gospel Out
 Silicon Graphics, Inc      /  http://reality.sgi.com/scotth/

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/