Messages in this thread | | | From | Steve VanDevender <> | Date | Sat, 26 Dec 1998 18:03:38 -0800 (PST) | Subject | Re: /dev/one - why not /dev/repeat? |
| |
Dave Cinege writes: > Steve VanDevender wrote: > > [ Stupidity snipped ] > > > Everything you list as examples of "useless bloat" are things > > that only the kernel can do properly in a multiuser system. > > #1 Serial console? edit /etc/inittab and put a getty on /dev/ttyS0
Not if you want to log boot messages to the serial console or boot without any VGA console at all.
> #2 /dev/nvram? userlandable
Not without providing the same kinds of concurrency control and access protection a kernel driver does.
> #3 intird? FS on the HD, or floppy. A custom 'init' will let you compress it.
Again, initrd is useful in the kernel because you can use it early in boot time.
> #4 romfs? Minix is already there. Use read only mode.
Isn't the point of romfs to make it more efficient to have a read-only filesystem in ROM than it would be to put a disk filesystem image in ROM, and especially to make it possible to boot from a ROM?
> NONE of these NEED to be in the kernel. They are in there because they work > BETTER, and offer greater flexablity.
That's the point. Putting them in the kernel allows them to do things they could not do as user applications, or to work at times when no user applications are running (i.e. during boot). /dev/repeat is actually something that will work better in a user application than it ever could as a kernel device (see below).
> > The point is that if you want to spew a lot of repeated data into > > a disk file, writing a small user-space utility to do it will > > actually be _faster_ (because it doesn't have to read() a block > > for every write() it does) and quite likely smaller than the > > amount of extra kernel code needed to implement a pseudodevice. > > THE POINT IS IT IS MUCH MORE FLEXABLE THEN THAT. Get it through your skull.
No need to shout. And I have thought it about, quite possibly more than you have.
There are several serious problems with the idea of /dev/repeat:
1. What are the semantics if multiple processes open it? Does the second process to open it and write a new stream cause susequent processes that open it for reading (or currently-running processes that have already opened it) to read different data? How does a process that has just opened /dev/repeat for reading know which data stream to get if two processes have written different data into /dev/repeat?
2. Denial-of-service attack: write a very long stream into /dev/repeat so that the kernel, as it buffers the input, exhausts kernel memory.
3. If the point is to provide a fast way to write large amounts of repeated data, there will always be the cost of making a system call to read a bufferful from /dev/repeat before writing it out somewhere. A user utility can fill a buffer once, then write it repeatedly using half the system calls.
So with all these problems, what's the flexibility advantage?
If you really need to do this, I suggest writing a C program that does the following:
1. Read standard input up to EOF and stash it in a buffer.
2. Duplicate the initial input as necessary (such as to LCM(BUFSIZ, length(stdin)) or to ceil(BUFSIZ / length(stdin)) * length(stdin)) to reduce write() overhead.
3. Write the buffer to stdout repeatedly, treating it as a ring buffer.
Now, this is both more efficient (because generating output can be done entirely with write() calls rather than read()/write() pairs) and works correctly in a multiuser situation (each user process contains the appropriate state). It's also going to be a lot shorter than a kernel device that has to maintain state for each process using it (assuming you could solve the hairy multi-user problems listed above), and your rather unusual application is the only thing to suffer any overhead from it, rather than asking all of us to take on the kernel bloat of this /dev/repeat driver just because _you_ think it's handy.
- 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/
| |