Subject: Linux-Development Digest #407
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Wed, 26 Jan 94 18:51:30 EST

Linux-Development Digest #407, Volume #1         Wed, 26 Jan 94 18:51:30 EST

Contents:
  Re: Xenix (haible@ma2s2.mathematik.uni-karlsruhe.de)
  Re: Shared Memory under Linux (Robert Sanders)
  SB16 SCSI-2 and Linux ????????? (Jaime A. Jofre)
  Re: Which is better? 680x0 or 80x86? ( Magdaleno)
  IP Multicasting (Terje Vernly)
  Which is better? 680x0 or 80x86? (-=| Bantolph |=-)
  Re: Linux v1.0: what's in it? (Mark Evans)
  Atari port (Richard Hodson)
  Re: is there a driver for National 8390 Ethernet Chip (Mark Evans)
  How to write a word to a port (inside a device driver). (Nick A. van Goor)
  Whoever was doing Token Ring driver please !! (Nigel Head)
  Re: Which is better? 680x0 or 80x86? (La Monte Yarroll)
  Re: kmalloc for more then 4096 Bytes ? (Matthias Urlichs)
  Re: Is there an _official_ directory structure for linux? (Matthias Urlichs)

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

From: haible@ma2s2.mathematik.uni-karlsruhe.de
Crossposted-To: comp.os.linux.help
Subject: Re: Xenix
Date: 24 Jan 1994 18:38:07 GMT

> Does anyone have a kernel patch or something to mount a Xenix partition?

Yes. On Sep 10 1993, Joe Portman <baron@hebron.connected.com> sent me the
following code. I haven't tested it, and of course it may need work for
newer Linux kernel versions, but anyway here it is.

divvy.h         -       defines the divvy table and bad track table layout.
genhd.c         -       only have to patch this file to recognize the sub-
                        partitions.

here is divvy.h
=================CUT HERE==================
#ifndef _DIVVY_H
#define _DIVVY_H
/*
** The structure of a Xenix System Disk
** All this code was derived by inspection of
** my own hard disks - JLP III
*/

#ifdef __GNUC__
#define __packed__  __attribute__ ((packed, aligned(1)))
#else
#error I want gcc!
#endif

#define XENIX_ROOT_PARTITION 2
#define XENIX_USER_PARTITION 3

/*
** divvy table is 42 blocks into the partition
** on my system. 2.3.4 may have moved this
** if I ever get 2.3.4, I will test it.
*/
#define DIVVY_OFFSET 42
#define XENIX_SUB_PARTS 16

/*
** bad track table is 44 blocks into the partition
** at least on my system it is - JLP
*/
#define BADTAB_OFFSET 44
#define XENIX_PARTITION_MAGIC   0x1234
#define BADTRACK_TABLE_MAGIC    0x4321

struct xenixparts
  {
         unsigned short magic;
         struct parts
                {
                  long offset __packed__; /* offset of logical sub-partition */
                  long size   __packed__; /* size of sub-partition */
                                          /* note - the size is in 1K blocks */
                }
         part[XENIX_SUB_PARTS];           /* I have never seen more than 7 */
                                     /* and the 7th is the whole partition - raw */
  };

/*
** generally if you have more than 50 - you are
** in trouble
*/

#define MAX_ALT_TRACKS 1023
struct bad_track_table
  {
         unsigned short magic __packed__;
         unsigned short maxbad __packed__;
         struct badtrks
                {
                  unsigned short trk __packed__;
                  unsigned short alt __packed__;
                }
         bad[MAX_ALT_TRACKS];
  };

#endif

================CUT HERE==============
and here is patched version of genhd.c
================CUT HERE==============
/*
 *  Code extracted from
 *  linux/kernel/hd.c
 *
 *  Copyright (C) 1991, 1992  Linus Torvalds
 */

/*
 *  Thanks to Branko Lankester, lankeste@fwi.uva.nl, who found a bug
 *  in the early extended-partition checks and added DM partitions
 */

#include <linux/config.h>
#include <linux/fs.h>
#include <linux/genhd.h>
#include <linux/kernel.h>
#ifdef CONFIG_XENIX_PARTITION_SUPPORT
#include <linux/divvy.h>
#endif

struct gendisk *gendisk_head = NULL;

static int current_minor = 0;
extern int *blk_size[];
extern void rd_load(void);
extern int ramdisk_size;
#ifdef CONFIG_XENIX_PARTITION_SUPPORT
static void xenix_partition(struct gendisk *, int );
#endif
/*
 * Create devices for each logical partition in an extended partition.
 * The logical partitions form a linked list, with each entry being
 * a partition table with two entries.  The first entry
 * is the real data partition (with a start relative to the partition
 * table start).  The second is a pointer to the next logical partition
 * (with a start relative to the entire extended partition).
 * We do not create a Linux partition for the partition tables, but
 * only for the actual data partitions.
 */

static void extended_partition(struct gendisk *hd, int dev)
{
        struct buffer_head *bh;
        struct partition *p;
        unsigned long first_sector, this_sector;
        int mask = (1 << hd->minor_shift) - 1;

        first_sector = hd->part[MINOR(dev)].start_sect;
        this_sector = first_sector;

        while (1) {
                if ((current_minor & mask) >= (4 + hd->max_p))
                        return;
                if (!(bh = bread(dev,0,1024)))
                        return;
          /*
           * This block is from a device that we're about to stomp on.
           * So make sure nobody thinks this block is usable.
           */
                bh->b_dirt=0;
                bh->b_uptodate=0;
                if (*(unsigned short *) (bh->b_data+510) == 0xAA55) {
                        p = (struct partition *) (0x1BE + bh->b_data);
                /*
                 * Process the first entry, which should be the real
                 * data partition.
                 */
                        if (p->sys_ind == EXTENDED_PARTITION ||
                            !(hd->part[current_minor].nr_sects = p->nr_sects))
                                goto done;  /* shouldn't happen */
                        hd->part[current_minor].start_sect = this_sector + p->start_sect;
                        printk(" %s%c%d", hd->major_name,
                                'a'+(current_minor >> hd->minor_shift),
                                mask & current_minor);
                        current_minor++;
                        p++;
                /*
                 * Process the second entry, which should be a link
                 * to the next logical partition.  Create a minor
                 * for this just long enough to get the next partition
                 * table.  The minor will be reused for the real
                 * data partition.
                 */
                        if (p->sys_ind != EXTENDED_PARTITION ||
                            !(hd->part[current_minor].nr_sects = p->nr_sects))
                                goto done;  /* no more logicals in this partition */
                        hd->part[current_minor].start_sect = first_sector + p->start_sect;
                        this_sector = first_sector + p->start_sect;
                        dev = ((hd->major) << 8) | current_minor;
                        brelse(bh);
                } else
                        goto done;
        }
done:
        brelse(bh);
}

static void check_partition(struct gendisk *hd, unsigned int dev)
{
        static int first_time = 1;
        int i, minor = current_minor;
        struct buffer_head *bh;
        struct partition *p;
        unsigned long first_sector;
        int mask = (1 << hd->minor_shift) - 1;

        if (first_time)
                printk("Partition check:\n");
        first_time = 0;
        first_sector = hd->part[MINOR(dev)].start_sect;
        if (!(bh = bread(dev,0,1024))) {
                printk("  unable to read partition table of device %04x\n",dev);
                return;
        }
        printk("  %s%c:", hd->major_name, 'a'+(minor >> hd->minor_shift));
        current_minor += 4;  /* first "extra" minor */
        if (*(unsigned short *) (bh->b_data+510) == 0xAA55) {
                p = (struct partition *) (0x1BE + bh->b_data);
                for (i=1 ; i<=4 ; minor++,i++,p++) {
                        if (!(hd->part[minor].nr_sects = p->nr_sects))
                                continue;
                        hd->part[minor].start_sect = first_sector + p->start_sect;
                        printk(" %s%c%d", hd->major_name,'a'+(minor >> hd->minor_shift), i);
                        if ((current_minor & 0x3f) >= 60)
                                continue;
                        if (p->sys_ind == EXTENDED_PARTITION) {
                                printk(" <");
                                extended_partition(hd, (hd->major << 8) | minor);
                                printk(" >");
                        }
#ifdef CONFIG_XENIX_PARTITION_SUPPORT
                  if (p->sys_ind == XENIX_ROOT_PARTITION) {
                                printk(" [");
                                xenix_partition(hd, (hd->major << 8) | minor);
                                printk(" ]");
                        }
#endif
                }
                /*
                 * check for Disk Manager partition table
                 */
                if (*(unsigned short *) (bh->b_data+0xfc) == 0x55AA) {
                        p = (struct partition *) (0x1BE + bh->b_data);
                        for (i = 4 ; i < 16 ; i++, current_minor++) {
                                p--;
                                if ((current_minor & mask) >= mask-2)
                                        break;
                                if (!(p->start_sect && p->nr_sects))
                                        continue;
                                hd->part[current_minor].start_sect = p->start_sect;
                                hd->part[current_minor].nr_sects = p->nr_sects;
                                printk(" %s%c%d", hd->major_name,
                                        'a'+(current_minor >> hd->minor_shift),
                                        current_minor & mask);
                        }
                }
        } else
                printk(" bad partition table");
        printk("\n");
        brelse(bh);
}

/* This function is used to re-read partition tables for removable disks.
   Much of the cleanup from the old partition tables should have already been
   done */

/* This function will re-read the partition tables for a given device,
and set things back up again.  There are some important caveats,
however.  You must ensure that no one is using the device, and no one
can start using the device while this function is being executed. */

void resetup_one_dev(struct gendisk *dev, int drive)
{
        int i;
        int start = drive<<dev->minor_shift;
        int j = start + dev->max_p;
        int major = dev->major << 8;

        current_minor = 1+(drive<<dev->minor_shift);
        check_partition(dev, major+(drive<<dev->minor_shift));

        for (i=start ; i < j ; i++)
                dev->sizes[i] = dev->part[i].nr_sects >> (BLOCK_SIZE_BITS - 9);
}

static void setup_dev(struct gendisk *dev)
{
        int i;
        int j = dev->max_nr * dev->max_p;
        int major = dev->major << 8;
        int drive;
        

        for (i = 0 ; i < j; i++)  {
                dev->part[i].start_sect = 0;
                dev->part[i].nr_sects = 0;
        }
        dev->init();    
        for (drive=0 ; drive<dev->nr_real ; drive++) {
                current_minor = 1+(drive<<dev->minor_shift);
                check_partition(dev, major+(drive<<dev->minor_shift));
        }
        for (i=0 ; i < j ; i++)
                dev->sizes[i] = dev->part[i].nr_sects >> (BLOCK_SIZE_BITS - 9);
        blk_size[dev->major] = dev->sizes;
}
        
/* This may be used only once, enforced by 'static int callable' */
extern "C" int sys_setup(void * BIOS)
{
        static int callable = 1;
        struct gendisk *p;
        int nr=0;

        if (!callable)
                return -1;
        callable = 0;

        for (p = gendisk_head ; p ; p=p->next) {
                setup_dev(p);
                nr += p->nr_real;
        }
                
        if (ramdisk_size)
                rd_load();
        mount_root();
        return (0);
}
#ifdef CONFIG_XENIX_PARTITION_SUPPORT
/*
** ok, read the logical disk partition,
** and calculate the position of each of the
** xenix sub-partitions, then add them
** I am not adding bad track support just yet
** as I use DPT controllers that do it for me
** still, you must allow for the size of the
** bad track table.
** OH, OH, trouble here. We need to know the
** physical characteristics of the device.
** Xenix does some cylinder alignment for the
** partitions and bad track area
*/

/*
 *  This struct defines the HD's and their types.
 */
struct hd_i_struct {
        unsigned int head,sect,cyl,wpcom,lzone,ctl;
        };
extern struct hd_i_struct hd_info[];
struct xenixparts xp;
struct bad_track_table btp;
static void xenix_partition(struct gendisk *hd, int dev)
{
        struct buffer_head *bh;
        unsigned long first_sector, bad_track_start, bad_track_size, real_start;
      
        unsigned int cylinders,sectors,heads;
        int x;
        int mask = (1 << hd->minor_shift) - 1;
        int drive = MINOR(dev) >> hd->minor_shift;

        /*
        ** we need the sectors, cylinders and heads for
        ** the drive so we can do cylinder alignment
        ** and track aligmnent
        */

        cylinders = hd_info[drive].cyl;
        heads       = hd_info[drive].head;
        sectors  = hd_info[drive].sect;

        first_sector = hd->part[MINOR(dev)].start_sect;

        if ((current_minor & mask) >= (4 + hd->max_p))
                return; 

        if (!(bh = bread(dev,DIVVY_OFFSET / 2,1024))) {
                printk("cannot read divvy sector %d from device %d \n", DIVVY_OFFSET, dev);
                return;
        }
        /* 
        ** save the divvy table into xp
        */
        memcpy(&xp,bh->b_data,sizeof(xp));
        brelse(bh);

        if (!(bh = bread(dev,BADTAB_OFFSET/2,1024))) {
                printk("cannot read badtrk sector %d from device %d \n",BADTAB_OFFSET, dev);
                return;
        }

        /* 
        ** note, bad track table might be up to 8 sectors (4096)
        ** so bad tracking might fail
        ** we are not using it, so just grab the data
        */

        /*
        ** save first two 512 byte sectors of
        ** bad track table
        */
        memcpy(&btp,bh->b_data,1024);
        brelse(bh);

        if (xp.magic != XENIX_PARTITION_MAGIC) {
                printk ("No magic number found for xenix partition, found %x \n",xp.magic);
                goto done;                              /* this should not happen */
        }

        if (btp.magic != BADTRACK_TABLE_MAGIC) {
                printk ("No magic number found for badtrack table , found %x \n",btp.magic);
                goto done;                              /* this should not happen */
        }

        /* 
        ** calculate the size and position of the bad track
        ** table. Bad track table is track aligned
        */
        bad_track_start = (first_sector + BADTAB_OFFSET + 7) / sectors ;
        bad_track_start++;
        bad_track_start *= sectors;
        bad_track_size = sectors * btp.maxbad;
/*      printk("Xenix bad track table, start %d, len %d \n",bad_track_start,
                                                                                                            bad_track_size); */
        /*
        ** calculate the real starting position in the partition
        */
        real_start = (bad_track_start + bad_track_size + 1) / (sectors * heads );
        real_start++;
        real_start *= (sectors * heads);

/*      printk("Xenix partition table first sector start %d \n", real_start); */
        for (x = 0;x < 7;x++) {
                if (xp.part[x].size == 1)       /* not a real partition */
                        continue;
                hd->part[current_minor].start_sect  = 
                                real_start + (xp.part[x].offset * 2);
                hd->part[current_minor].nr_sects  = xp.part[x].size * 2;
                printk(" %s%c%d", hd->major_name,
                        'a'+(current_minor >> hd->minor_shift),
                        mask & current_minor);
                current_minor++;
        }
done:
        return;
}
#endif

=============CUT HERE===========


                    Bruno Haible
                    haible@ma2s2.mathematik.uni-karlsruhe.de


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

From: gt8134b@prism.gatech.EDU (Robert Sanders)
Subject: Re: Shared Memory under Linux
Date: 24 Jan 94 17:44:37 GMT

hash@cs.umd.edu (Kevin Hsu) writes:

>I know these will sound like dumb questions:

>       - How is shared memory under Linux? If it is implemented, how much
>               shared memory is allocatable in a single segment?

A little under 4 MB.  You can have 128 segments in the system.

>       - I need to be able to call functions from shared libraries, WITHOUT
>               knowing at compile time specifically which functions I want to
>               call. Any ideas on how to implement this?

Well, do you mean all from one shared library, or different libraries?
Pre-existing libraries, such as libc, or application-specific?  You
can use dld to load and "link" to any .o files at runtime.  dld 3.2.3
has been ported to Linux by Aubrey Jaffer for his excellent 'scm'
Scheme interpreter.

From the dld Info file:

   "Dld" is a library package of C functions that performs "dynamic
link editing".  Programs that use dld can add compiled object code to
or remove such code from a process anytime during its execution.
Loading modules, searching libraries, resolving external references, and
allocating storage for global and static data structures are all
performed at run time.


--
 _g,  '96 --->>>>>>>>>>   gt8134b@prism.gatech.edu  <<<<<<<<<---  CompSci  ,g_
W@@@W__        |-\      ^        | disclaimer:  <---> "Bow before ZOD!" __W@@@W
W@@@@**~~~'  ro|-<ert s/_\ nders |   who am I???  ^  from Superman  '~~~**@@@@W
`*MV' hi,ocie! |-/ad! /   \ss!!  | ooga ooga!!    |    II (cool)!         `VW*'

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

Crossposted-To: comp.os.linux.help,comp.os.linux.misc
From: jjofre@etsd.ml.com (Jaime A. Jofre)
Subject: SB16 SCSI-2 and Linux ?????????
Reply-To: jjofre@etsd.ml.com
Date: Wed, 19 Jan 1994 19:45:20 GMT

Hi,
  Is the Sounblaster 16 SCSI2 interface supported by any of the Linux
SCSI drivers?  The tech support guy at Creative Labs said that the card
uses an Adaptec 1610 chip.  Any hints?  Thanks in advanced,

Jaime



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

From: cooljohn@leland.Stanford.EDU ( Magdaleno)
Subject: Re: Which is better? 680x0 or 80x86?
Date: 24 Jan 1994 19:21:50 GMT

This argument is going to be passe' in a couple of months when the PowerPC
computers will be released. (Of course the Amiga will still have it..)

-John


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

From: terjeve@ifi.uio.no (Terje Vernly)
Subject: IP Multicasting
Date: 24 Jan 94 18:51:42 GMT


Has anyone added the IP Multicast extensions (described in rfc1112)
to Linux yet?

--

  +----------------------------------------------------------------+
  | Terje Vernly                   "The dead know only one thing : |
  | EMail: terjeve@ifi.uio.no       It is better to be alive."     |
  +----------------------------------------------------------------+

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

From: bantolph@unm.edu (-=| Bantolph |=-)
Subject: Which is better? 680x0 or 80x86?
Date: 24 Jan 1994 11:43:36 -0700

I am a mechanical engineer and not very knowlegable on the guts of 
microprocessors or operating systems so please pardon my ignorance.

All of the recent discussion on Linux on the mac has made me come up
with a few questions. Which is a better processor for running a UN*X
like operating system on, the Motorola 680x0 series or the Intel 80x86
series? I have heard a few people complain about 68000's not being able
to multitask well so they switched to Intel chips. Is there any truth 
to this? What makes a chip a good candidate for running a multitasking
OS, lots of on chip cache, lots of registers, fast bus? How do these two
series of chips compare with respect to these factors?

Sorry to be so inquisitive, this probably isn't the place to post this
and I should really look the stuff up myself but I would appreciate
any answers.

Thanks,

Ken



+------------------------------------------------------------------------+
| Kenneth L. Cope                       Internet: bantolph@draco.unm.edu |
| 4224 Commanche Rd NE                            cope@amac.plk.af.mil   |
| Albuquerque, NM 87110                                                  |
| (505) 883-4388   home                                                  |
| (505) 846-9772   work                                                  |
+------------------------------------------------------------------------+
| "Ninety percent of computer users use DOS. I'd rather tell them to do  |
|          drugs."  ---Scott McNealy, CEO, Sun Microsytems               |
+========================================================================+


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

From: evansmp@mb48025.aston.ac.uk (Mark Evans)
Subject: Re: Linux v1.0: what's in it?
Date: Mon, 24 Jan 1994 20:04:13 GMT

Rob Janssen (rob@pe1chl.ampr.org) wrote:

: The networking code still is not 'as good as' that in BSD.  Unfortunately,
: there are only a few knowledgable people working on it, and even in
: this small group there are differences in opinion on what is the right
: way to solve problems (and to treat fellow developers)

Also the fact that in quite a few ways the code does not follow the
host or gateway requirements.

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

From: richard@radar.demon.co.uk (Richard Hodson)
Subject: Atari port
Date: Mon, 24 Jan 1994 23:42:59 +0000

Is anyone out there porting Linux to the Atari TT? I heard rumour of
such a port ages ago, but have seen no evidence. The 680x0 mailing list
seems very quiet.

I am currently running Linux on a 386/40, and have a TT and all the
Atari developer docs. Seems a shame to have all that CPU sitting next to
me, and having to run Linux on a little 386 box.

--
Richard Hodson                                |  richard@radar.demon.co.uk
And his amazing fetish for dangly earrings... |  rhodson@cix.compulink.co.uk

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

From: evansmp@mb48025.aston.ac.uk (Mark Evans)
Subject: Re: is there a driver for National 8390 Ethernet Chip
Date: Mon, 24 Jan 1994 20:13:52 GMT

Donald J. Becker (becker@super.org) wrote:

:       Linux device support is only home-grown: it will be a long time before
:       vendors include Linux drivers with their hardware.  If they don't
:       get a driver from us, they won't get it at all.

The problem is that certain manufactures of both ethercards and interfaces on
the motherboard are reluctent to release programming details.

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

From: nick@verdi.engr.utk.edu (Nick A. van Goor)
Subject: How to write a word to a port (inside a device driver).
Date: Tue, 25 Jan 1994 02:13:38 GMT

Greetings,

I am trying to write a device driver in Linux for a
DT2821 series data translation board. I read the FAQ and 
the Hacker's Guide, and it seems a driver for this board
is not yet available.

Not being a CS major, not all of the stuff I've read seems
obvious to me, so I'm sure I'll have lots of questions as I 
go along. I have quite some programming experience, just not 
the kernel type programming. 

Anyway, here's my first question:

The manual of the board tells me that (and I quote) "all
registers are 16-bit wide, and are word accessible only".
The Hacker's Guide lists several functions which read/write
bytes to specified ports (inb* and outb*).
My question is are there functions available which read/write
words to ports ? If not, is there a quick and easy way for
me to modify the inb* and outb* functions so that they
write words ? Any helpful tips/hints/comments would be
greatly appreciated, since I would hate to have to dive into
the assembler jungle to solve it that way.

Thanks,

Nick


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

Date: Mon, 24 Jan 1994 11:42:49 CET
From: Nigel Head <NHEAD@ESOC.BITNET>
Subject: Whoever was doing Token Ring driver please !!

I remeber someone remarking that they were looking into Token Ring drivers ...
if you ever got anything even half way functioning I'd love to hear from you!


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

From: piggy@hilbert.maths.utas.edu.au (La Monte Yarroll)
Subject: Re: Which is better? 680x0 or 80x86?
Date: 25 Jan 1994 02:14:26 GMT

bantolph@unm.edu (-=| Bantolph |=-) writes:

>I am a mechanical engineer and not very knowlegable on the guts of 
>microprocessors or operating systems so please pardon my ignorance.

You won't larn nut'n witout ask'n.

BTW, this topic can spawn religious wars, so tread lightly.  My own
bias should be clear below.

>All of the recent discussion on Linux on the mac has made me come up
>with a few questions. Which is a better processor for running a UN*X
>like operating system on, the Motorola 680x0 series or the Intel 80x86
>series? I have heard a few people complain about 68000's not being able
>to multitask well so they switched to Intel chips. Is there any truth 
>to this? What makes a chip a good candidate for running a multitasking
>OS, lots of on chip cache, lots of registers, fast bus? How do these two
>series of chips compare with respect to these factors?

The one thing needed to support a multi-tasking OS is memory
management.  The 68000 did not have an MMU, but neither did the 80286.
The 68010 included some minimal MMU support, and could thus run a fair
version of Un*x.  The memory segmenting hardware of the 80286 allowed
some MMU-like operations, and so it was possible to run decent toy
versions of multi-tasking OS's like COHERENT 3.0.  The 80386 and 68020
both have real MMUs and so are capable of running full versions of
Un*x-like OS's.

One the whole, Motorola's chips (680x0) have much more symetric
architectures than Intel's chips (80x86, aka ix86).  Each register on
an 80x86 has it's own distinctive personality which means that the
registers are not completely interchangable.  This means that the
680x0 line is easier to program in assembly language, and is
theoreticly easier to write good compilers and operating systems for.
In practice, the huge market share of the Intel parts has brought
about good software even for Intel's twisted chips.

Compiler writers like CPU's with lots of interchangable registers, but
that's because it makes register allocation easier--this has little to
do with multi-tasking.

On-chip cache, fast bus, and high clock speed all make most things go
faster, but they are just icing.  You can run a full-fledged Un*x on
a 386SX16, or a 10Mhz 68010--you just have to spend a little more time
waiting.

[I'm so proud of myself--I didn't use the phrase "Evil Intel" once! :-]
--
La Monte H. Yarroll     Home:           piggy@baqaqi.chi.il.us
   Work:                piggy@hilbert.maths.utas.edu.au
   Sometimes:           postmaster@clout.chi.il.us
   If you remember nothing else:  piggy@acm.org         NIC Handle: LY

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: kmalloc for more then 4096 Bytes ?
Date: 24 Jan 1994 23:38:37 +0100

In comp.os.linux.development, article <CK1G8u.MBs@ra.nrl.navy.mil>,
  eric@tantalus.nrl.navy.mil (Eric Youngdale) writes:
> 
>       Newer kernels have vmalloc which allows you to allocate memory in more
> or less any size you want.  kmalloc is still available, and it is preferable
> for blocks that are < PAGE_SIZE since it makes better use of the memory, and I
> think it is faster.
> 
It also works from interrupt code, unlike vmalloc. Since the lower layers of
Linux networking are interrupt level code, using vmalloc and thus using big
NFS buffers won't work.

BSD networking uses buffer chains ("mbufs") to work around this, but Linux
networking has different ideas -- and fitting a different buffering scheme
into the networking code is a lot more difficult than just grabbing the
BSD networking code and stuffing it into Linux whole (more or less).

The latter has been done (by me), and I'm using that code while I type this,
but it'll need a few more interfaces and some interoperability fixes which
are a bit too far down in my priority queue right now.  :-(

-- 
Bedfellows make strange politicians.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Is there an _official_ directory structure for linux?
Date: 24 Jan 1994 23:48:48 +0100

In comp.os.linux.development, article <2hrad3$ach@crl.crl.com>,
  bhogan@crl.com (Bill Hogan) writes:
> 
>   If this is really and truly such a big deal that it has to be said
> first, before even so much as saying "G'day", instead of being put at the
> end, where it belongs, as in "BTW", then why isn't this newsgroup _called_
> "comp.os.linux.kernel"? 
> 
The problem is that there's no way to draw a sharp line between "kernel" and
"non-kernel". This "official directory structure" stuff is an example.
After all, the kernel has to find /sbin/init (/etc/init, /bin/init).  ;-)

The charta was written to explicitly exclude things "development which just
happens to be on a Linux platform", which boils down to about 95% of the
programs which people might want to compile+run on their Linux system. 
If everybody and their dog asked general Unix-programming-related questions
here, c.o.l.d be inundated and Linux-specific work would be even more
impossible than it is anyway. ;-)

It was _not_ written to exclude everything that isn't touched when you
build your kernel. If that were the case, this newsgroup would indeed be
named c.o.l.kernel.

-- 
CONCEPT:
       Any "idea" for which an outside
       consultant billed you more than $25,000.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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


** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

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

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

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