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

Linux-Development Digest #142, Volume #2          Fri, 9 Sep 94 06:13:04 EDT

Contents:
  Re: Non-ANSI constructs in the kernel (was Re: Unicode...) (Andries Brouwer)
  Re: Non-ANSI constructs in the kernel (was Re: Unicode...) (Andries Brouwer)
  Re: Looking for Donald Becker (Steve Kann)
  Re: News Spool File System - new filesystem type?? (Tom Limoncelli)
  Re: Mach64 XServer 90MHz limitation (Marc Aurele La France)
  Shadow-mk? (MacGyver)
  Re: Americans vs. Europeans (was Re: Unicode...) (Vassili Leonov)
  Re: Future of linux -- the sequel (Erik Fortune)
  Re: Future of Linux (David Holland)
  Re: Network driver section for the Hacker's Guide (Orhan Unal)
  Re: Anyone working on ISDN card drivers ??
  How to use diff (Tracy R. Reed)
  Re: Multiprocessing Pentium Systems (Bouwmeester L.)
  Re: News Spool File System - new filesystem type?? (Alan Cox)

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

From: [email-masked] (Andries Brouwer)
Subject: Re: Non-ANSI constructs in the kernel (was Re: Unicode...)
Date: Thu, 8 Sep 1994 16:38:32 GMT

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

>I keep hearing about how UTF-8 is just around the corner, and how the ker-
>nel has removed all assumptions about characters and strings.  Yet a quick
>perusal of the source brings to light a host of constructs in the source
>that violate ANSI principles of internationalization.  For example, in
>./include/linux/ctype.h we find the following macro:

>#define tolower(c) (_ctmp=c,isupper(_ctmp)?_ctmp-('A'-'a'):_ctmp)
>#define toupper(c) (_ctmp=c,islower(_ctmp)?_ctmp-('a'-'A'):_ctmp)

>Let me quote for a moment from the internationalization FAQ.  
...
>Here's another tidbit of the same sort from the HPFS code:
>    static inline int memcasecmp(const unsigned char *s1,
...

I do not think you point at serious problems.
Concerning HPFS, the README says:

! Linux can read, but not write, OS/2 HPFS partitions.
...
! There is one mount option unique to HPFS.
!
!  case=lower    Convert file names to lower case.  [default]
!  case=asis     Return file names as is, in mixed case.
!
! Case is not significant in filename matching, like real HPFS.

So in this case it seems that Linux is correctly simulating the
OS/2 HPFS behaviour, and if you dislike that behaviour you should
complain to the people who designed that file system. For Linux
it is just a given.

Concerning toupper and tolower, they occur (i) to convert hexadecimal
digits a-f to A-F, and (ii) on a tty where IUCLC or OLCUC is set.
The former use has nothing to do with internationalization.
In the latter case you may have a point. Not that the wrong conversion
is done (isupper and islower just return 0 for non-ASCII bytes), but
no conversion is done where you might have wanted one, like from
e-acute to E-acute.
However, the kernel, very rightly, does not assume anything about
the character set you are using, and hence cannot know how to
convert non-ASCII bytes to upper or lower case.
[I hope you do not propose to replace "All the world is ASCII" by
"All the world is ISO-8859-1".]
In fact IUCLC and OLCUC are obsolete flags allowing one to use a Unix
system from a terminal that is only capable of producing upper case
letters. It is unlikely that such a terminal would be able to produce
e-acute etc. So, I think this is a non-issue.

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

From: [email-masked] (Andries Brouwer)
Subject: Re: Non-ANSI constructs in the kernel (was Re: Unicode...)
Date: Thu, 8 Sep 1994 16:49:22 GMT

[email-masked] (Harald T. Alvestrand) writes:

>The toupper() and tolower() macros are IMHO broken.

You must distinguish what the kernel uses internally from
what applications use. The kernel has no business knowing
anything about character sets, and indeed no assumptions
are made (other than NUL and /). You can have filenames made
out of line-drawing characters, so that ls produces a nice picture.

The only reason toupper/tolower occurs in the kernel is this old IUCLC/OLCUC
tty mode, and in that context I would not regard them as broken.

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

From: [email-masked] (Steve Kann)
Subject: Re: Looking for Donald Becker
Date: 9 Sep 1994 01:48:37 -0400

Erann Gat ([email-masked]) wrote:
: Does anyone know what happened to Donald Becker?  He is the author of
: many of the Linux network device drivers.  He is apparently no longer
: at super.org.

Donald's mail should be forwarded from super.org to his current address.

If you want it to get there directly, send it to:

[email-masked]

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

From: [email-masked] (Tom Limoncelli)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: 9 Sep 1994 00:54:20 -0400

In <[email-masked]> [email-masked] (Bill Davidsen) writes:

>I have thought of writing a complete news system using this method, which
>would restrict reading to NNTP, since the file structure would be all
>diferent. Not a loss, I think. I'm still looking for a fast algorithm to
>find N consecutive bits ON in a bitmap...

Why?

NNRP and INN have all the hooks to support all of this already.  Why
re-invent the wheel when you only have to change the "read article"
and "write article" routines of INN or C News?

--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] (Marc Aurele La France)
Subject: Re: Mach64 XServer 90MHz limitation
Date: 8 Sep 1994 20:38:41 GMT

In article <[email-masked]>,
 Weng Loh ([email-masked]) wrote:
> I am currently playing with "alpha" driver for the ATI
> Mach64 chipset XServer posted on sunsite.unc.edu. 

> The configured clocks for that chipset goes up to 135Mhz
> (or thereabout) but the server does not like seeing any
> clock set above 90Mhz.

> I have tried rebuilding the server ( XFree_SVGA using
> the alpha ATI driver.c ) after changing the include
> file x386.h def for the default max clock rate to
> 150000 (150Mhz) and remade all files. However the
> rebuilt Server still complains if I specify a clock
> over 90MHz.

> This is proving to be a real nuisance as my ATI
> card needs a 100Mhz clock to do the resolutions
> above 1024x768 at acceptable (70Hz) refresh rates.

> Does anybody know if there are other parts of the
> server that needs to be patched to overcome this
> 90MHz clock limit?

It is the driver that sets the limit, not the server.  And I don't
recommend increasing it.  The limit should in fact be 80MHz.  The reason
is the RAMDACs used with these boards cannot be safely driven higher than
80MHz.  Some RAMDACs can be put into a special operating mode to overcome
this limitation.  The 2.1.1 vgawonder driver has no support for this (yet).
Neither will 3.1.

If you insist on increasing the limit, you will risk damaging the RAMDAC.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-403-492-9310           |
|  Computing and Network Services  |  fax:    1-403-492-1729           |
|  352 General Services Building   |  email:  [email-masked]  |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+

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

From: [email-masked] (MacGyver)
Subject: Shadow-mk?
Date: 9 Sep 1994 00:32:02 -0500

Hi there,

I currently use the Shadow 3.3.2 distribution found on sunsite.unc.edu in
pub/Linux/system/Admin and I read a post a little bit ago about shadow-mk
fixing security holes in login and such...do these holes exist in Shadow
3.3.2 and if so, how do I go about fixing them.

Thanks,

HJD.

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

From: [email-masked] (Vassili Leonov)
Subject: Re: Americans vs. Europeans (was Re: Unicode...)
Date: 7 Sep 1994 23:13:03 GMT

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

: I see what you mean.  This is the attitude many Americans take to their
: European counterparts - the thing that so annoys Europeans:  The idea
...
: The same remarks applied to US programmers re Europeans, BTW, may be
: applied to Europeans vis-a-vis the rest of the world (i.e. the majority
: of the world - which speaks languages like Urdu, Chinese, Arabic, etc.).

The problem is that it's rather easy to staisfy Europeans, and they
are rather pushy in that. To put it plain in order to make Europens
happy (at least one at a time :-) you should remember:
CHAR need 8 bits. Don't ever use control codes > 128.

With Chineese it's much much more obscure... I really don't know how
to do this, how to do this clean, etc. There is no simple solution.
AND most people that need >8bit don't even push that matter. I remember
most of pople from Europe are using their national character sets for
writing e-mail - but never seen anything Chineese of Japaneese here.
So...

Vassili.

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

From: [email-masked] (Erik Fortune)
Subject: Re: Future of linux -- the sequel
Date: 8 Sep 1994 17:04:56 GMT

In article <[email-masked]>, [email-masked] writes:
> I think the memo should not be read as a complaint against a certain
> version, but more in a general sense.  That is probably also why it was
> posted in a Linux mailing list (as a warning what might happen when you
> don't watch for bloat in the system).
> 
> The Indy is mentioned several times, like in
> 
>       "Indy: an Indigo without the 'go'"
At the time it was written, "Indy" was synonymous with Irix 5.1 (5.1
did not run on any other system).   Regardless of how *you* believe the
memo should be read, it was a complaint about the then current version
of the OS for the Indy -- Irix 5.1.

> My Linux system has 16M RAM, and I have never had the feeling that I should
> expand the RAM to get reasonable performance.  Of course, more RAM is
> always nice, but Linux runs just fine with 16M.  I use it only with X,
> and I normally have about 6 xterms open all the time, and over 60 processes
> in the process table (most of them waiting, of course).
You really should use an Indy for awhile before you start making comparisons
to Linux.  Out of the box and Indy delivers a *lot* more than 6 xterms.   If 
you disable all of the filesystem monitoring, desktop tools, etc that come 
with the Indy then a 16 meg system is fine.   It's a less "friendly" system 
(though still much nicer to non-hackers than Linux), but performance is fine.

Look, I *like* linux and run it on several machines.   For me it's great.
Then again, I turn off a lot of the desktop stuff on my Indy too -- I don't
need it.

> However, this is not what the thread is all about.  The point is that the
> original statement that an Indy makes a Pentium feel like a 4.77MHz XT
> was a gross exaggeration, and that still stands.  
I use both and the Indy feels much faster.   No, not 50x faster but still
a lot faster.

> The memo only shows that SGI has had performance problems as well.  
> It would be a real feat when the difference between 5.1 and 5.2 was 
> between something that is too slow to work with and something that is 50 
> times as fast as a Pentium, but I *really doubt* this is the case.
System performance improved quite dramatically with Irix 5.2.
IMO a 16M configuration that was unusably slow with Irix 5.1 is acceptable 
under 5.2.   Systems with 32M+ and/or many of the desktop features disabled
were fine before 5.2.

-- Erik

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

Subject: Re: Future of Linux
From: [email-masked] (David Holland)
Date: 7 Sep 94 14:49:16

[email-masked]'s message of 31 Aug 1994 21:45:55 -0700 said:

 > Okay, but I have a setup like most new Linux users: 14' monitor, 1
 > meg card.  640x480 is pleasant but not enough real estate.  800x600
 > is too small to work at for extended periods.  1024x768 is
      ^^^^^^^^^
 > masochistic.  So what do I do?  I run charmode, that's what.

Use a bigger font then...

--
   - David A. Holland          | -- "Do you have a moment?"   -- "Yes.
     [email-masked] | Unfortunately, it's a moment of inertia."

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

From: [email-masked] (Orhan Unal)
Subject: Re: Network driver section for the Hacker's Guide
Date: 8 Sep 1994 19:52:39 GMT

In article <[email-masked]> [email-masked] (Erann Gat) writes:
>I am in the process of writing a new network driver, and I thought it
>might be worthwhile to turn the experience into a currently misssing
>section
>of the Linux Kernel Hacker's Guide on network drivers.  However, if I am
>going to do that I would like to hook up with an experienced Linux
>developer to help me make sure that I am doing the Right Things.  Is
>there anyone out there, preferably with some net driver experience,
>willing to help me out with this project?
>
>Many thanks,
>E.
>
>-- 
>
>Erann Gat
>[email-masked]

I suppose you can get in touch with the following people.

Here is an excrept from the "CREDITS" file.

N: Donald Becker
E: [email-masked]
D: General low-level networking hacker
D: Most of the ethercard drivers
D: Original author of the NFS server
S: 17100 Science Drive
S: Bowie, Maryland 20715
S: USA

N: Alan Cox
E: [email-masked]
E: [email-masked]
E: GW4PTS@GB7SWN (packet radio)
D: NET2Debugged author
D: Network layer debugging
D: AX.25 & IPX alpha releases
S: <No>
 
-- 
********************************************************
*  Orhan Unal  *  Email: [email-masked]  *
********************************************************

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

Date: Thu, 8 Sep 1994 08:31:49 +0200
From: [email-masked] ()
Reply-To: [email-masked]
Subject: Re: Anyone working on ISDN card drivers ??

In article [email-masked], [email-masked] (Olaf Titz) writes:
> In article <19940901.145536.270665.NETNEWS@esoc>,  <[email-masked]> wrote:
> > If anyone is working on or knows of ISDN drivers for Linux systems please would you
> > let me know ??  I'm considering moving into the digital world and I need some
>
> There is an ISDN driver that is unfortunately based on a heavily
> patched kernel (but works well). It currently supports only the Teles
> "dumb" ISDN card (the cheapest :-) and the German ISDN standard.
>
> ftp://ftp.uni-stuttgart.de/pub/unix/linux/isdn
>

Thanks - I'll follow this up ... using a cheap card doesn't sound like too
much of a problem to me :-)

This has been the only answer so far. I can't really believe that all you
IP service providers out there aren't using Linux machines !!!!

Nigel.

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

From: [email-masked] (Tracy R. Reed)
Subject: How to use diff
Date: 9 Sep 1994 08:09:06 GMT

I need to know how to use diff to make a patch. I manually applied the 
1.1.18 accounting patch to 1.1.49 because the diffs didn't work out quite 
right. I would now like to make a new diff so I don't have to do it by 
hand again. I saved the old kernel in /usr/src/linux-old and the new 
kernel is in /usr/src/linux. Can someone give me the diff command to 
compare these to directories and make a patch? My installation doesn't 
have a manual page for diff for some reason. I'll make the patch 
available to anyone who wants it.

--

=============================================================================
Mr. Tracy Reed         |Every artist is a cannibal.| Why did dad cry 
San Diego State Univ.  |Every poet is a thief.     |  when I gave him
Aerospace Engineering  |All kill their inspiration |  Willmaker 1.0?
[email-masked] |And sing about their grief.|
[email-masked]      |-U2 IRC-Maelcum /me smiles |  
=============================================================================

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

From: [email-masked] (Bouwmeester L.)
Subject: Re: Multiprocessing Pentium Systems
Date: Fri, 9 Sep 1994 07:22:01 GMT

[email-masked]. (Tim Morley) writes:

>In article <[email-masked]>,
>David Williams <[email-masked]> wrote:
>>
>>I've just seen some new dual processor pentium systems in Computer
>>Shopper.  They look swell for the money, but there isn't a single OS
>>that can take advantage of them.  Anybody have any thoughts about how
>>hard it might be to make Linux one of the first OS's to take advantage
>>of these systems?

>Well it would be hard to do so, as OS/2 SMP already exists and is
>avaliable for dual processor machines...

>We could be the first _FREE_ OS to support it though 8-)

Actually, some *initial* work is going on in that area! We are currently
working on a kernel that supports threads (the Viper kernel: an 
enhancement of the Linux kernel). This kernel provides a sound basis for 
a true real-time and/or multi-processor kernel.

The design is for 99% ready and re-structuring of the kernel data structures
has already started. In fact, we have a first kernel running that 
*understands* the threads data structures. Next step is to provide threads
scheduling (and that is a hard bitch :-)).

Regards,
        Leon

-- 
+----------------------------------------------------------------------------+
|Ir. L.H.A. Bouwmeester      PTT Research, Dr Neher Laboratorium             | 
|Phone : +31-(0)70-3325864   Network Service and Control Department, rm E120 |
|Fax   : +31-(0)15-3326477   St. Paulusstraat 4, 2264XZ, Leidschendam        |

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

Crossposted-To: news.software.b
From: [email-masked] (Alan Cox)
Subject: Re: News Spool File System - new filesystem type??
Date: Fri, 9 Sep 1994 09:31:38 GMT

In article <[email-masked]> [email-masked] (Bill Davidsen) writes:
>For what it's worth, I did a BBS which kept it's own message base instead
>of using one file per message. It worked REALLY well, and I'm rewriting it
>as client server now to solve some locking overhead when multiple processes
>do certain operations.

I've seen people run micro based news readers that pulled each article from
a tar file as needed (along with an index file so the tar reader could
just seek and grab the article). It is a good idea.
>diferent. Not a loss, I think. I'm still looking for a fast algorithm to
>find N consecutive bits ON in a bitmap...

A tree. Given N bitmaps you have N/M lists giving the largest empty sequence
or bits in each of the N bitmaps. You can also have N/M^2 lists of largest
sequences in lists to any level desired. Finding is then trivial, deleting
isn't very hard (scan back/forward from the bits your set), opening requires
a single pass of that specific bitmap.

Worked ok for HB3, even though that BBS code never got finished.

Alan

-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  [email-masked]   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

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

** 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
******************************