On Thu, 6 Aug 1998, Andrea Arcangeli wrote:
> >1) No need for userland created devices, as the driver will register them
> >for you.
> But then you still (of course) have to care about owners and permissions
> so an additional MAKEDEV is not a big overhead compared.
Yes, but this isn't that bad. A simple tar will do.
> >2) Quicker access to the resource due to no waiting for a big /dev
> >directory lookup.
>
> andrea@dragon:/tmp/prova$ while :; do >$RANDOM; done
>
> andrea@dragon:/tmp/prova$ ls | wc -l
> 4182
> andrea@dragon:/tmp/prova$ ls | head -1
> 1
> Broken pipe
> andrea@dragon:/tmp/prova$ time ls -l 1
> -rw-rw-r-- 1 andrea internal 0 Aug 6 01:29 1
>
> real 0m0.087s
> user 0m0.010s
> sys 0m0.010s
In saying waiting, I wasn't meaning the human style foot tapping, coffee
getting, *long wait* that it might have sounded like. I meant that little
bit of time spent is unnecessary. Bigger deal for some than others, no?
> >3) Less administrative overhead in maintaining /dev and a MAKEDEV script.
>
> You need to save and restore properties and ownership of devfs every
> boot/shutdown.
Yes, I do admit this. That's two times total that you touch the disk just
to have complete /dev functionality, as apposed to one disk/cache hit for
every device access. One tar to restore on boot, and one to save on
shutdown.
> >4) No maj/min device node limits, such as the number of them you can have.
>
> Yes, good workaround.
I truely do think it addresses some fundamentally bad things about having
standard device inodes. A /proc like solution is nice, wouldn't you say?
I mean, when you tweak /proc/sys/vm stuff it's not like it stays there
from boot to boot, right?
The save/restore thing is the only real noticable difference as far as I'm
concerned. At least as far as the compatibility is concerned.... As for
the rest of the differences, I think they're good ones.
-Shawn
<=========== America Held Hostage ===========>
Day 2023 for the poor and the middle class.
Day 2042 for the rich and the dead.
899 days remaining in the Raw Deal.
<============================================>
-
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.altern.org/andrebalsa/doc/lkml-faq.html