New (GNU) kernels--what I think

[Marcus Leech]

In article <4366 at ficc.uu.net>, peter at ficc.uu.net (Peter da Silva) writes:
> >  Options should be complete words,
> 
> No, I think not. We still want to run UNIX shell scripts.
Note that if you use the minimum unambigous rule, nearly no shell scripts
  would have to be changed. Perhaps a environment variable that controls
  which getopt() syntax table to use.
> >   I'm not sure how wonderful the shm*() calls are.  TCP/IP networking is a
> >   must--it should be tunable at run-time (I'd like to see the KA9Q code in
> >   the kernel, with some performance enhancements).
> 
> This doesn't make sense when taken together with your call to remove I/O
> from the kernel.
I didn't call for the removal of I/O from the kernel. I just said that it
  (the I/O kernel subsystem) should be decoupled enough from the rest of
  the kernel to make I/O hardware less-capable of crashing the system.  If a
  non-kernel implementation of TCP/IP can be found that satisfies all the
  performance and semantic requirements, I'm all for it.  I've been involved
  in playing with the KA9Q code, and concluded that the only way to get
  it "nice" is to put it in the kernel as a pseudo-device driver.
> 
> No, they should pull the next or previous lines from a circular buffer in
> the driver. If you're going to duplicate the history mechanism in all
No.  History buffers of a user-selectable arbitrary size don't belong in
  the kernel, which I why I suggested the callback-like interrupt mechanism.
  Other mechanisms, as I said, might suggest themselves.
-- 
"Better Living through modern chemistry" PaperMail: 130 Colonnade Rd, Nepean,ON
Marcus Leech                             E-mail:     ml at gandalf.UUCP
Gandalf Data Ltd                         PacketRadio: VE3MDL at VE3JF
"The opinions expressed herein are solely my own" So there