NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/3b1/3105

Internet Message Format | 1992-08-16 | 5.0 KB

Path: sparky!uunet!beartrk!ceilidh!hijo-2!dnichols
From: [e-mail] (Don Nichols (DoN.))
Newsgroups: comp.sys.3b1
Subject: Re: Potential kernel mods...
Message-ID: <[e-mail]>
Date: 16 Aug 92 19:56:54 GMT
References: <[e-mail]>
Distribution: usa
Organization: D and D Data, Vienna Virginia
Lines: 101

In article <[e-mail]> [e-mail] (John 'Fritz' Lowrey) writes:
>    Folks,
>    With there being a potential for at some access to the source for
>our pet machine, I think that this would be an ideal time to consider a
>few improvements that some kernel hackers could implement that would make
>all of our lives easier.  By improvements, I mean things that could be
>done that would improve that performance and usability of the 3b1/7300
>without completely altering the system.  Now, don't all shout out things
>like "BSD file system!!", or "X Windows!!", be rational about the abilities
>and limitations or the machine.
>    My proposals are:
>
>    = Eliminate default polling of the OBM and phone status lines.

    Yes!  Make it a loadable driver, so it is optional.

>    = Rebuild the kernel with gcc.
>       Let's face it, it make better code.

    We may have to re-compile other programs which interact with the
kernel (like ps, ktune, etc) so they have the same parameter-passing
behavior.)

>    = Clean up the memory addressing (is this in the kernel proper, or
>      in the boot loader?).
>       Allocating whopping big chunks of virtual address space to the
>       kernel and shared libraries may make the addressing calculations
>       easier, but for those with .5 or 1MB, the paging is terrible!

    I think that the hardware limits the maximum page size to 4k, but it
a far cry from 4k to 0.5M

>    = Maybe a leaner, meaner kernel without the TAM windowing.
>       I personally have hacked some things with this system (and I am
>       working on some others), but there are some with no need for the
>       code overhead (the MGR folks for instance).

    Again, make it an optional loadable device driver, if possible.

>    What are some other alterations that 3b1 users would like to see in
>a 3b1-kernel v4.0?  Lay it on, let's see what comes out.  Respond to the
>net, unless you think it is something that only I, in my ignorance or supreme
>understanding |-), might be interested in.

    Put in various things to make porting of BSD programs (and writing
of new ones) easier.

1)    Build the dirent rountines into the shared libs (which would need to
    be redone, anyway).

2)    Add in mkdir(2) and rmdir(2), and perhaps the BSD reliable signals.

3)    Add in kernel support for #! interpretation, with configurable
    options as to whether it would honor suid/sgid shell scripts,
    depending on individual security needs.  (Obviously, support for
    suid shell scripts would simplify things like manually kicking off
    news processing or batching out of the scheduled times.  On the 3B1,
    I have to log in a root, and then su to news in the shell script.
    If I could have a suid news script, it would simplify the process.
    (Obviously, I wouldn't enable this in the presence of any but the
    most trustworthy user base. :-) We have proof that the #!
    implementation can be done in the libraries, but I haven't yet
    checked whether it honors suid status when so implemented. ... O.K.
    I just checked it, and it does *NOT* honor suid or sgid status.
    Well, that's safer than having it honor with no way to turn it off.
    :-)

3)    Keep the ethernet driver as a loadable device driver, but clean it
    (and its libraries) up so they are closer to BSD standards.

4)    Make the kernel hooks so that another filesystem type *could* be
    supported with a loadable device driver, for those of us who are
    willing to pay the kernel bloat overhead.  This would not only allow
    the possibility of BSD fast filesystem implementation, but also
    allow NFS mounted filesystems (shared from Suns, etc.)  My Suns have
    SCSI, and can handle disks up to 1GB each (more if I had a SPARC
    based machine with the latest 4.1.2 SunOs).  These systems are
    willing to share access to the disks, and I do so within the cluster
    of Suns.  There is no support for this in the present kernel, nor do
    I see a way to accomplish it with a loadable device driver, because
    the kernel expects only a single filesystem type.

    I think that I have managed to confine myself to the things which
need kernel support to do properly.  (You can simulate mkdir(2) with a sys
to mkdir(1), with possible other code to fix ownership, but a clean
implementation requires kernel support.)

    Obviously, many other things can be implemented at the library
level, or at user level, especially if you have daemons with the right
priviliges.

    I wish that I had time to take part in the kernel work.  Maybe when
I retire.

    Thanks
        DoN.
--
Donald Nichols (DoN.)     | Voice (Days): [phone] (Eves): [phone]
D&D Data                  |  Email: <[e-mail]>
I said it - no one else   |         <[e-mail]>
    --- Black Holes are where God is dividing by zero ---