Subject: Linux-Development Digest #133
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Wed, 7 Sep 94 04:13:06 EDT

Linux-Development Digest #133, Volume #2          Wed, 7 Sep 94 04:13:06 EDT

Contents:
  Re: News Spool File System - new filesystem type?? (Tom Limoncelli)
  Re: Aliasing `rm' (Erik Corry)
  Re: Future of linux -- the sequel (Dave Platt)
  Re: cat /proc/interrupts doesn't show printer ints. (Glenn Moloney)
  Re: Unicode & Linux's future (was Re: Acid) (Andries Brouwer)
  Re: Unicode & Linux's future (was Re: Acid) (Andries Brouwer)
  Re: Linux and Novel Print server? (Mark Evans)
  Re: Future of linux -- the sequel (Rob Janssen)
  Re: Serial port problems (Rob Janssen)
  Re: Novell routing between IPX/TCPIP? (Rob Janssen)
  Re: Has ARP been fixed ? (Rob Janssen)
  Status of Mac Linux & PPC Linux? (Zack T. Smith)
  Re: Status of Mac Linux & PPC Linux? (Hamish Macdonald)
  Re: [STATUS] Linus Floppy Driver Development (WE Metzenthen)
  /proc/mtab progress

----------------------------------------------------------------------------

From: [email-masked] (Tom Limoncelli)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: 6 Sep 1994 19:55:52 -0400

In <[email-masked]> [email-masked] (Michael Dillon) writes:

>I wonder if message-id's could be worked in there somehow?

Obviously, $NEWSSPOOL/id.index/message-id could refer to the actual
article.  You wouldn't haven't to support opendir()/closedir(), just
open().

--tal
-- 
Tom Limoncelli -- [email-masked] (home) -- [email-masked] (work)
Write to me for info about internet mailing lists on these topics:
Drew University Alumni/ae, IXO/tpage users, New Jersey Unix Sysadmins' Group
(like SAGE), New Jersey motss, North East motss, BiNet/New Jersey, and more!

------------------------------

From: [email-masked] (Erik Corry)
Subject: Re: Aliasing `rm'
Date: Tue, 6 Sep 1994 03:26:45 GMT

Christian Henry ([email-masked]) wrote:
: In article <[email-masked]>,
: Yves Arrouye <[email-masked]> wrote:

: >     1. Alias rm. What's bad is that when I used it under tcsh I spent my
: >     time typing someting like '\rm ...' just to not use the alias (I hate
: >     being asked if I really want to do what I said I want to do). I'm sure
: >     I'm not the only one which did that...

: Why didn't you just pass the `-f' switch to rm (rm -f whatever)?  ;-)

'rm -f' is really bad for interactive work, because it never reports errors,
-- 
Erik Corry, Skagerrakstr. 2, 79100 Freiburg, Germany, +49 761 406637
[email-masked]

------------------------------

From: [email-masked] (Dave Platt)
Subject: Re: Future of linux -- the sequel
Date: Tue, 6 Sep 1994 18:58:38 GMT

In article <[email-masked]> [email-masked] (Conrad Steenberg) writes:

> WHY is no one even CONSIDERING doing a multiprocessor kernel for Linux?
> It doesn't matter which multiprocessor board, but the fact is that there
> are multiprocessor 486 and Pentium motherboards out there... they are even
> affordable (of all things ;-). OS/2 from IBM comes with a multiprocessing
> kernel (SMP no less...) so it is not impossible, even though it may be 
> hard on a few programmers' sleep.

And, I imagine, somebody will probably tackle the job once those
multiprocessor boards (or systems) become more of a commodity.

It is not a trivial job to turn a kernel designed for one processor into
a kernel which can really do a good job of handling multiple processors.
You end up having to add a lot of semaphore locking/unlocking code.
Getting it to work cleanly, reliably, and efficiently is a lot of work.

> One could probably go on like this for ages, but it probably comes down to
> the fact that the guys doing the slick programming doesn't have the slick
> hardware...<sigh>.

Yup.
--
Dave Platt    [email-masked]
      USNAIL: The 3DO Company, Systems Software group
              600 Galveston Drive
              Redwood City, CA  94063

------------------------------

From: [email-masked] (Glenn Moloney)
Subject: Re: cat /proc/interrupts doesn't show printer ints.
Date: 6 Sep 1994 23:01:54 GMT

In article <[email-masked]>,
 <[email-masked]> wrote:
> The Subject says it all. I am *almost* sure my printer uses INT7, as I set it
>by tunelp, and it works, and if I set it to another value, it doesn't. Kernel
>version is 1.1.49. Could someone hint if one can do something to make the
>printer interrrupts counter displayable? Many thanks,

Some drivers only request interrupts when they are opened, and release
them when closed. An example is the floppy driver, which uses interrupt
6, but only requests the interrupt (request_irq()), while a floppy is
open. Hence IRQ 6 does not appear in /proc/interrupts (except whil
accessing the floppy). I have not
checked if this is the case with the lp driver.

This is a good thing, in that it allows different
devices to use the same interrupts (if used at different times).
However, it reduces the usefulness of the /proc/interrupts file.

There may be some usefulness in device drivers registering with the
kernel what resources (irq,dma,port addresses,shared memory) the
software and hardware use. This useful system config information could
then be made available in the /proc filesystem. I have several cards and
device drivers installed on my system, and it would be nice to find a
/proc entry to find free irqs, dma channels and port adresses for
instaling new cards on the system. It would make managing many Linux
boxes in a laboratory type situation a lot easier (particularly if you
have device drivers which auto detect the hardware, but don't
permanently grab the IRQ).

I may just look into it :-). Any suggestions or comments welcome.

>
> Andrew Yakovlev. 

                                        cheers,
                                        glenn.

-- 
                                        
  Glenn Moloney                         [email-masked]
  School of Physics,                    Phone: +61 3 344 5081
  University of Melbourne,              Fax:   +61 3 347 4783
  Parkville, Australia 3052.

------------------------------

From: [email-masked] (Andries Brouwer)
Subject: Re: Unicode & Linux's future (was Re: Acid)
Date: Tue, 6 Sep 1994 22:31:38 GMT

[email-masked] (Richard L. Goerwitz) writes:

>[email-masked] (Joachim Schrod) writes:
>>
>>Take Khmer as an example, where syllables form clusters around a
>>`determining glyph'.

The Unicode standard V1.0, Vol. 1, p. 636: "Burmese and Khmer are
being investigated."

>>Unicode might be a nice thing, but it does not care for many scripts
>>of this world; so it will not be THE solution, either. ('Though it
>>would be a Good Thing to have support for it more widespread.)

>No, I understand that many have serious philosophical differences over
>whether diacritics should be included as separate characters or not.
>This dispute has apparently been resolved inclusively via the ISO
>10646 - Unicode merger (the details of which I am not familiar with).

As I understand it, all combinations letter+diacritic(s) that already
have a code point in some existing standard coding also got a code point
in Unicode, in order to make 1-1 conversions to and from this earlier
standard possible. In all (other) cases Unicode represents letter+diacritic
as a sequence of two or more symbols, that is, the diacritics are treated
as separate non-spacing characters that follow the base symbol.

------------------------------

From: [email-masked] (Andries Brouwer)
Subject: Re: Unicode & Linux's future (was Re: Acid)
Date: Tue, 6 Sep 1994 22:39:11 GMT

[email-masked] (Alan Cox) writes:

>In the case of the Linux kernel this isn't too drastic. Firstly there is almost
>no core operating system assumption about strings present. The single glaring
>one is the '/' symbol and ascii NUL. An encoding that keeps ascii NUL
>special is a good idea from C points of view. The / would need the kernel
>to know the basic primitive rules to spot / as opposed to a / as part of
>a 16bit symbol. Keeping this straight when doing NFS with a non multi
>lingual system will be fascinating 8).

That is why in the UTF-8 encoding of Unicode no ASCII symbol can occur
as part of another symbol. This solves both the NUL and the / problems.

>Yes. There are standard tools and library functions for this already in the
>current kernels. Again they 'think' 8 bit bytes still but the basics are
>there to be extended on including things like foreign dates, foreign
>collation orders (sorting) etc. Stuff like the C library is already 
>internationalised, and having seen how irritating a German release is to
>English people I'm now trying to internationalise the network tools. The
>current stuff isn't really sufficient as far as I can see for 16bit unicode
>although its close to it and since I'm quite new to the nlcat functions
>I may have missed something.

I hope to release a new kbd-0.** this month. It will contain a kernel
patch with some Unicode support. (Just a start. The fonts are still
missing, but loadkeys will be able to assign 16-bit values to the keys,
and the keyboard driver will have a UTF-8 mode converting these 16-bit
values into byte sequences.)

------------------------------

From: [email-masked] (Mark Evans)
Subject: Re: Linux and Novel Print server?
Date: Tue, 6 Sep 1994 20:17:39 GMT

James MacLean (jmaclean@localhost) wrote:
: root ([email-masked]) wrote:
: :   I know this is most likly not possible.   What I want to do is find 
: : a way I can print to my novel print server?  How would
: : I do that?   Any suggestions.  Robert
: : [email-masked]

: Another option is always to bring up DOSEMU, load up NETX and print via
: 'capture'.

It is being worked on.

------------------------------

From: [email-masked] (Rob Janssen)
Subject: Re: Future of linux -- the sequel
Reply-To: [email-masked]
Date: Tue, 6 Sep 1994 22:27:16 GMT

In <[email-masked]> [email-masked] (Conrad Steenberg) writes:

>One of the original poster's questions is seemingly completely ignored, even
>though it is much more relevant than whether chip X or system Y is faster/
>cheaper than a Pentuim at Z MHz, so let me ask that question:
> 
> WHY is no one even CONSIDERING doing a multiprocessor kernel for Linux?
> It doesn't matter which multiprocessor board, but the fact is that there
> are multiprocessor 486 and Pentium motherboards out there... they are even
> affordable (of all things ;-). OS/2 from IBM comes with a multiprocessing
> kernel (SMP no less...) so it is not impossible, even though it may be 
> hard on a few programmers' sleep.

Apparently you are not reading this group for more than about two weeks,
or you would have caught one one of the *many many* threads about SMP Linux
that have been here before.

The answer to your question is: because it is *complicated*.  it sure isn't
impossible, but the fact that IBM have been able to do it in a multi-man-year
project is of hardly any relevance to the Linux developer world, I think.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: [email-masked] (Rob Janssen)
Subject: Re: Serial port problems
Reply-To: [email-masked]
Date: Tue, 6 Sep 1994 22:53:55 GMT

In <[email-masked]> [email-masked] (Joerg Wedeck) writes:

>Hi,

>as the subject says i am having problems with the serial port with
>ALL linux kernels, when switching to speeds higher than 19200 baud.
>from 38400 baud on onward i have to experience data losses.

WHICH linux kernels do you mean by ALL linux kernels?

>the manual says there are 2 NS16C552 compatible UARTs which support
>FIFO. Are these UARTs incompatible to the serial driver provided by
>linux ?

I use a card with three of these, and one of my ports runs at 76800 bps
to my modem.  flowcontrol works perfectly.

>it appears to me that hardware flow control is failing (it definitely
>works when trying under dos).

There was a recent change to eliminate a flow control bug (although I
did not see that one on my system, many others didn't have problems,
some people did)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: [email-masked] (Rob Janssen)
Subject: Re: Novell routing between IPX/TCPIP?
Reply-To: [email-masked]
Date: Tue, 6 Sep 1994 23:11:41 GMT

In <[email-masked]> [email-masked] (Bob Kaehms) writes:

>(the way tin's acting, I may have asked this a while back, but since
>I didn't hear any replies....)

>Does anyone have any ideas on how I could turn Linux into a router for
>both TCPIP and IPX?  what would it take to get IPX routing available on
>Linux? Buy-in from Novell?  Anyone familar enough with IPX to know whether
>or not this is doable without Novell?

IPX routing is fully documented by Novell.  Much of it is already
in Linux.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: [email-masked] (Rob Janssen)
Subject: Re: Has ARP been fixed ?
Reply-To: [email-masked]
Date: Tue, 6 Sep 1994 23:16:30 GMT

In <[email-masked]> [email-masked] (Anders Ostling) writes:

>Hi guys

>It seems like the ARP module is broken. It lists all my entries with
>completely invalid IP addresses, but correct MAC address. Is somebody
>working on this ? Is it solved ? When did it break ?

I don't know what you mean by "the ARP module", but what is broken is
only the printout.  It will be solved by updating your network utilities.
ARP itself works okay, and there is nothing to worry about.
It broke when the format of /proc/net/arp was changed.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

Crossposted-To: comp.os.linux.help
From: [email-masked] (Zack T. Smith)
Subject: Status of Mac Linux & PPC Linux?
Date: Wed, 7 Sep 1994 00:06:52 GMT

Hi,

Can anyone tell me what the status of each of Mac Linux and PowerPC Linux
is? Last time I checked the archives for Mac Linux, it seem that nothing
new had been posted. Is Mac Linux dead? How about PPC? Is it up and running
to any extent?

Thanks in advance,

Zack Smith

------------------------------

From: [email-masked] (Hamish Macdonald)
Crossposted-To: comp.os.linux.help
Subject: Re: Status of Mac Linux & PPC Linux?
Date: 7 Sep 1994 01:04:05 GMT

>>>>> On 06 Sep 1994 19:06:52 EST,
>>>>> In message <[email-masked]>,
>>>>> [email-masked] (Zack T. Smith) wrote:

Zack> Can anyone tell me what the status of each of Mac Linux and
Zack> PowerPC Linux is? Last time I checked the archives for Mac
Zack> Linux, it seem that nothing new had been posted.

I haven't heard any progress reports about the Linux/68k port to the
Mac for a while.  I understand that getting information about the
Macintosh hardware is difficult.

------------------------------

From: [email-masked] (WE Metzenthen)
Subject: Re: [STATUS] Linus Floppy Driver Development
Date: 7 Sep 1994 01:21:56 GMT

David C. Niemi ([email-masked]) wrote:
: 2)    mke2fs does not work correctly (if at all) on certain floppy
:       formats.  18, 20, 21, and 22-sector HD 3.5" formats do not work.
:       This problem was introduced with 1.1.41.  To reproduce:

: <insert a formatted 3.5" 1.44MB floppy>
: dd if=/dev/zero count=20 of=/dev/fd0H1440 # Clear out existing file sys.
: mke2fs /dev/fd0H1440
: <promptly remove the floppy as soon as the drive light goes out>
: <reinsert floppy>
: e2fsck -f /dev/fd0H1440

:       Note that this occurs even if syncs are used, or if e2fsck is
:       performed right away before removing the floppy.  However, if
:       "e2fsck -f" is performed immediately after the mke2fs, the
:       problem does not occur.

:       Interestingly, this problem does not occur on the DD and ED
:       formats that I tried, nor on 23-sector or 24-sector HD formats.

:       This problem was first reported on 82077s and attributed to the
:       FIFO, but I am skeptical that it is limited to 82077s as it still
:       occurs if I force the driver to regard the FDC as an 8272a.

I can confirm that this bug is not restricted to 82077 controllers.  I
have an old no-name hd/fd controller card in my system which has an
8272A chip on it.  I have noticed the bug since 1.1.47.  The real-world
situation where this bug is annoying is when you want to pre-format
some disks:
             fdformat /dev/fd0H1440
             mke2fs /dev/fd0
             <remove disk>
will result in a disk with an invalid e2fs file system on my machine.

The bug appears to be one of not flushing data to the disk.  It doesn't
appear to happen with mkfs or dd.

--
Bill Metzenthen
Mathematics Department
Monash University
Clayton, Victoria, Australia
email: [email-masked]
       [email-masked]

------------------------------

From: [email-masked] ()
Subject: /proc/mtab progress
Date: 7 Sep 1994 01:49:43 GMT
Reply-To: [email-masked]

HI all!

People asked for filesystem type to be ascii name. I made it.
In the superblock structure an entry for struct file_system_type *
is required (1.1.49):

--- linux/fs/super.c    Sat Aug  6 23:46:57 1994
+++ linux-proc/fs/super.c       Sun Sep  4 00:17:25 1994
@@ -288,6 +288,7 @@
        s->s_covered = NULL;
        s->s_rd_only = 0;
        s->s_dirt = 0;
+       s->s_type = type;
        return s;
 }

--- linux/include/linux/fs.h    Sun Sep  4 23:19:18 1994
+++ linux-proc/include/linux/fs.h       Sun Sep  4 00:16:22 1994
@@ -272,6 +272,7 @@
        unsigned char s_lock;
        unsigned char s_rd_only;
        unsigned char s_dirt;
+       struct file_system_type *s_type;
        struct super_operations *s_op;
        unsigned long s_flags;
        unsigned long s_magic;

After this, /proc/mtab can be nicer.
  0. nuber of the entry 0, 1, 2...
  1. major/minor number of mounted device
  2. covered inode number of the device on which it mounted
  3. major/minor number of the device on which it mounted
  4. mounted inode (replaces covered inode)
  5. ascii filesystem type
  6. HEX flags

In reality, it looks like
$ mount
/dev/hdb6 on / type ext2 (defaults)
/dev/hdb7 on /vol/usr type ext2 (defaults)
/dev/hdb5 on /vol/usr1 type ext2 (defaults)
/dev/hda1 on /hd/a1 type msdos (defaults)
/dev/hdb1 on /hd/b1 type msdos (defaults)
/proc on /proc type proc (defaults)
03:03:12 emard:/tmp/proc
$ cat /proc/mtab
0: 3/70          2 3/70          2 ext2 0
1: 3/71         45 3/70          2 ext2 0
2: 3/69       4368 3/70          2 ext2 0
3: 3/1        7923 3/70          1 msdos 0
4: 3/65       7924 3/70          1 msdos 0
5: 0/1         155 3/70          1 proc 0
03:03:18 emard:/tmp/proc
$

Hope this will be helpful. New procfs v0.1 for 1.1.49 is uploaded on
sunsite.unc.edu:/pub/Linux/Incoming/procfs01-1149.tgz. Send your
comments, bug reports etc to me.

Best regards, Davor
--
<[email-masked]>, <[email-masked]>
================ Davor Jadrijevic ====================

------------------------------

** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [email-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************