From: P D H (pdh@netcom.com)
Date: 04/28/93


From: pdh@netcom.com (P D H)
Subject: my list of things to do on linux
Date: Thu, 29 Apr 1993 00:01:46 GMT

This is my list of things to do on linux. Things are not apparently in
the FAQ. I have only been able to read the contents list and a few of
the questions at this time. Eventually I will get through all of the
questions and if any information is not well categorized by the question
asked, I can find it then (I have found stuff like this already, and this
does seem to be the norm for most FAQs anyway).

For things not yet answered, those who know may want to answer, or those
who want to know might get in touch with me and see what we can do together
to find out. It would seem silly to have 2 people separately research all
the same stuff just to find out the same things.

1. I want to change the VGA DAC's to hold specific color values. It has
    been suggested I look in the vgalib for some VGA related stuff. Maybe
    that will be in there, too. It would be really nice if the DACs could
    be set distinctly for each virtual console (the driver will have to
    keep them and reload them each time there is a change of console).

2. I would like to find out if it is possible to format floppy disks, and
    use them with, different sectoring/formatting than the usual to get more
    than the standard 1440k on 3.5 HD floppies. There are tools to do
    this for DOS, both to format and to make DOS put more filesystem data
    on them. Those programs have no source code. I suspect this might need
    a floppy driver hack and some changes in fdformat.

3. I want to do fax modem operations from Linux. My initial need is to
    send faxes from ordinary ASCII files. Later sending ghostscript would
    be nice as well. A simple raw interface would be a useful tool.

    Eventually fax reception would be nice, too.

4. I'm still trying to get serial I/O to work. I've run out of IRQs and
    apparently none can be moved up to the extended IRQs. I may look into
    sharing IRQs and see what I might do to the serial driver to handle
    the shared condition (such as always check all serial ports that share
    it for every interrupt). I know this is messy and unsafe, but there
    isn't much else to do unless someone wants to give me one of those 4 port
    serial cards and a couple of modems.

5. I want to make the kernel easy to compile without touching the kernel
    sources in the standard place. I think I now have a way to do this
    with only a hack to the first Makefile and a shell script in front.
    I'll probably be trying this out tonight (thanks to HJ Lu for the info).
    Then I want to make sure my hack won't defeat things others do so it
    can be eventually incorporated into the kernel source tree setup.

6. I am planning a program that will handle writing raw data on floppy
    disks. The idea is to make it possible to write a bunch of data to
    a stack of floppies with a pipeline like:

        tar cf - . | gzip | fdwrite /dev/fd0

    and read it back like:

        fdread /dev/fd0 | gunzip | tar xvpf -

    What the fdwrite and fdread programs would do is instruct you to insert
    the correct floppy in the drive in sequence. It would be something like:

        fdwrite: insert blank floppy number 6 and press return (ESC to abort)

    There would be no filesystem per se on the floppy this way. It would
    be strictly a sequential concept. If you want a filesystem, Linux has
    that already.

    The features I would like to include would be to format the floppy as
    this process is being done. I would ideally like to interleave the
    formatting and writing on a track by track basis. Verification can
    therefore verify that the actual data is written. I am wondering if
    there is any way to make the floppy controller write my data instead
    of the standard format_fill_byte during the format pass to speed this.

    I would also want to had the fdwrite program try to write the first
    track and do the format only if it fails (with options to abort instead
    of format, or to always format). Then there is the issue of whether to
    format all the remaining tracks when the data does not fill up the last
    floppy. That perhaps should be an option, and might require doing the
    "if write fails, format and write again" method on each track.

    It is this program that inspired the question of squeezing more data
    onto a floppy. Any suggestions or hints for this?

-- 
| Phil Howard,  pdh@netcom.com,  KA9WGN         Spell protection?  "1(911)A1" |
| Right wing conservative capitalists are out to separate you from your MONEY |
| Left wing liberal do gooders are out to separate you from EVERYTHING ELSE!! |
+-----------------------------------------------------------------------------+