lkml.org 
[lkml]   [1998]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: /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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.073 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site