lkml.org 
[lkml]   [1999]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRE: [linux-usb] Re: USB device allocation
    In <Pine.LNX.3.95.991008110717.897A-100000@chaos.analogic.com> Richard B. Johnson (root@chaos.analogic.com) wrote:
    RJ> 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.

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

    Why it's so important ?

    RJ> Any 'devfs' cannot violate the Unix policy or you don't have Unix.

    And what if I'm not want Unix ? Keep something to be "unix way" just for sake
    of keeping it "unix way" looks really stupid to me.

    RJ> This whole discussion is moot. What is needed is a larger dev_t.

    Devfs can do much more then just expanded dev_t ...

    RJ> It could be a structure (as proposed) or it could be a N-bit word.
    RJ> It doesn't matter, these are implementation details. Because of
    RJ> the way dev_t, both in the kernel, and in the C runtime library, is
    RJ> accessed, any change will break practially everything. So changes
    RJ> must be carefully thought out.

    On other hand adding devfs breaks MUCH less things.

    RJ> Presently, a kernel that uses 'struct dev_t' will boot and then
    RJ> fail to do anything useful after that. Every program that accessed
    RJ> files (practically all, if they use standard I/O), will have to
    RJ> be recompiled using a new 'C' runtime library that was modified to
    RJ> use the new dev_t structure. This is a lot of work, but will probably
    RJ> eventually have to be done.

    Hmm. With devfs you can avoid all this. Even if it's not "Unix way".

    RJ> Something called 'devfs' where only existing hardware has entries
    RJ> written in 'dev' fails to address the problem. It is not the amount
    RJ> of names (directory entries) that we are running out of, it is the
    RJ> amount of available values in major/minor device numbers.

    Correct. And when device is identified by name and not by major/minor number
    internally you have no such problem in first place.

    RJ> The Unix-like kernel knows only major/minor device numbers, not names.

    Which POSIX standard says how unix-like kernel acts inside ???

    RJ> If you have so many devices that you need major number N, you are
    RJ> presently screwed if N is greater than can be represented in the
    RJ> current dev_t.

    You hardly will have more then 65536 devices (dev_t size) and still now
    we have size of dev_t as limiting factor...

    RJ> So instead of inventing a new Operating System that doesn't use
    RJ> major/minor device numbers, I feel that time would be better spent
    RJ> extending the current dev_t. I personally like the structure approach
    RJ> because shifts/ANDs/ORs are machine-specific while a properly aligned
    RJ> structure is not.

    Unfortunatelly dev_t structure is also not "unix way". Since you can not
    use assignment in C for dev_t. And if we are going to go out of "unix way"
    anyway then why it should be dev_t definition and not some other thing ?




    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:54    [W:0.026 / U:0.892 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site