[lkml]   [1998]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
    On Thu, 6 Aug 1998, Richard Gooch wrote:

    >If you look back at my earlier patches, you'll notice that I had the
    >register_chrdev() calls wrapped in #ifndef's. Ingo pointed out that it
    >added lots of extra #ifndef's to the patch and that it was ugly. He

    I haven' t understood very well (I have not old devfs code here) but I
    sure trust Ingo more than me ;-).

    >suggested the change that I made to call devfs_register_chrdev()
    >instead. I checked with Linus and he agreed that replacing the calls
    >with a wrapper function was neater. So what you see there is *not* an
    >indication of intent to throw away compatibility, it is done to make
    >the code neater.

    There are still too much #ifdef for a production patch I think.

    >To some extent, I do support your idea of putting the smarts in
    >register_chrdev() instead. However, there are some problems with this:
    >- I'd have to hack *every* driver. The devfs patch only hacks some of
    > the drivers

    Are you going to provide a full replacement for /dev/?

    >- Not all drivers can use a simple #minors scheme. Either the names
    > aren't of the form "%s%d" or there isn't a contiguous set of minors.


    >However, that said, there may be merit in a hybrid scheme, where
    >register_chrdev() has extra parameters added to it, including one
    >which say "don't register a devfs entry: I'm going to do it myself".
    >This is something I'd have to think about. I'm not sure how much
    >things would be cleaned up.

    Of course. My idea of extending register_chrdev() was pretty general, but
    I don' t think that an hybrid scheme can be a lot clean.

    >Perhaps, although see above. Not everything has such a simple
    >arrangement of device numbers/names.

    Yes, in some cases you could need to handle the naming in the lowlevel

    >> There' s no need of the many config option you added. You don' t
    >> need to add config option at all. Applying the devfs patch should
    >> result in a completly different device scheme. Why to not use devfs
    >> at all (breaking old names and so on) if it would work far better?
    >No, no, no! Devfs *must* have a compatibility option: people need to
    >be able to switch between devfs and non-devfs kernels. Also, as we've
    >seen, some people don't like the new SCSI names.

    So put in only the config option of the compatibility names (to allow
    booting from an old userspace btw). If I apply devfs it means that I am
    going to use it. If your replacement is really good you have not to care
    of the old worse code.

    >I'm considering writing a small C programme that does the saving and
    >restoring of permissions instead of using tar.

    I am not worried by tar.

    >> The only useful thing of devfs is the workaround of the device
    >> drivers kdev_t numer without have to play with userlevel code. The
    >> only people that you replyed "use devfs to do that" was asking about
    >> how to handle >16SCSI disk.
    >This isn't true. Think also about USB. Think about when we have 16 bit

    People asked you about USB?

    >majors and we have a search operation for every open of a device node
    >(the existing table indexing scheme will have to be thrown out).

    I have not understood very well (I don' t know a lot about USB).

    >> devfs could result nice since it autodetect every device driver in the
    >> kernel and in hardware but note that nobody other than people that is
    >> playing with devfs run a ls in /dev/. The last time I had to do something
    >> /dev/ related (but I probably I have not run a ls /dev/) was on:
    >> andrea@dragon:~$ ls -l /etc/fstab
    >> -rw-r--r-- 1 root root 797 Feb 3 1998 /etc/fstab
    >I don't agree here, either. Well before I started thinking about
    >devfs, I would from time to time need to check something in /dev. I
    >always found it too cluttered. I even went down the path of deleting
    >inodes, only to have to put them back later when I started adding new
    >hardware :-(

    Richard, running MAKEDEV a few times it' s very faster and simpler than
    implement devfs ;-).

    Andrea[s] Arcangeli

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:43    [W:0.024 / U:35.656 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site