Linux-Development-Sys Digest #317, Volume #6 Fri, 22 Jan 99 05:14:13 EST
Contents:
Re: Linux unchanged for over two years...?! (Phil Howard)
Re: How to run Windows Applications on Linux (Jim Richardson)
Re: pre8, modules and problem with aha152x (Peter Ross)
Packages problem ([EMAIL PROTECTED])
Re: How can I build a Linux system from scratch - NO distribution? (Christopher
Browne)
Re: Linux Phase 2: A Consumer Operating System (Christopher Browne)
Re: How to tell current kernel config? (Kenneth Porter)
Re: Obtaining MAC address from remote computer (George MacDonald)
Re: INT13 disk driver (Villy Kruse)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: Linux unchanged for over two years...?!
Date: Fri, 22 Jan 1999 01:54:31 GMT
On 18 Jan 1999 17:34:59 -0500 Johan Kullstam ([EMAIL PROTECTED]) wrote:
| Mark Tranchant <[EMAIL PROTECTED]> writes:
|
| there is a lot of merit to this claim. 2.2.0 has indeed taken a long
| time to arrive. 2.0.0 came out over two years ago. ideally, 2.0.x
| should be bug fix releases only. thus, to a large extent, 2.0.36 is a
| two year old kernel with minor fixes.
And "taking a long time" can be a good thing. Instead of having the
pressue to ship the product, as is typical in the commercial software
world, Linux (and much of the freeware that makes the whole system
what it is) development can take the time necessary to "get it right".
| however, due to the long devel cycle and rapidly changing world of
| hardware, new drivers have been added to 2.0.x. so 2.0.36 does have
| some more recent features. 2.2.0 really does add some new features
| most notably multiple cpus in the kernel for smp boxen. this is a
| good thing for multi-cpu servers which need to do a lot of disk i/o
| for example.
I've been running a dual CPU system from around 2.0.20-something up
to 2.0.36. Yeah, technically experimental, but aside for a couple
of unexplained inode block corruptions (which I have also seen on
non-SMP machines) which might be due to hardware, the SMP code has
been very solid.
I do look forward to see if things like SCSI (particularly involving
the Adaptec drivers) error recovery improves. More than 80% of my
reboots are due to the attempt to recover errors of devices on the
SCSI bus causing the rest of the system to go nuts or go south. The
error recovery needs to do a better job like actually resetting the
bus instead of claiming to do so and not doing it, and not lock up
the machine while spinning in timing loops, and give up the attempt
to recover after either some amount of time (configurable) or when
root says to.
The frame buffer feature looks interesting. _Maybe_ it will let me
do some things that SVGAlib failed to let me do. It would be nice if
this would enable a kernel level switch from X to VC instead of having
to depend on X being runnable to do it. The kernel woul have to know
a lot more about the video card register states to be able to do this
kind of thing, and maybe the frame buffer code can do it. Even if not
that, it will be nice if I can have some fonts on the VC that aren't
restricted to being 8 or 9 pixels wide and limited to a maximum of
256 different characters (Unicode comes to mind here).
I'm also anxious to use the noatime option on filesystem mounts. I plan
to have that enabled on all but /var/spool/mail. All those inode upates
when I frequently scan directories or make checksums of all my files is
getting annoying.
Besides that and more drivers what else is there? I'm sure a lot, but I
just haven't heard much, yet.
I would like to have a generic network interface device that allows a
process to open a device in /dev to "be the hardware" and receive IP
packets routed to that interface and inject IP packets to "arrive" on
that interface into the stack. Yeah, I know I can do that with ppp and
a pty, but I'd prefer a cleaner interface without the limitations, and
that does not emulate any particular class of network interface (so that
I can, for example, have any MTU I choose).
--
-- *-----------------------------* Phil Howard KA9WGN * --
-- | Inturnet, Inc. | Director of Internet Services | --
-- | Business Internet Solutions | eng at intur.net | --
-- *-----------------------------* philh at intur.net * --
------------------------------
From: [EMAIL PROTECTED] (Jim Richardson)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: How to run Windows Applications on Linux
Date: 21 Jan 1999 02:56:49 GMT
Reply-To: [EMAIL PROTECTED]
On 19 Jan 1999 00:18:09 -0600,
Peter Samuelson, in the persona of <[EMAIL PROTECTED]>,
brought forth the following words...:
>[Jim Richardson <[EMAIL PROTECTED]>]
>> Is it truly possible to run win32 apps even without a windows
>> partition? I'd sure like to recover the rest of my hard drive.
>
>My understanding (and I myself haven't bothered to tinker Wine into
>working yet) is that the only thing you really need a Windoze directory
>for is those Windoze DLL's that Wine hasn't replaced yet. Eventually I
>believe the Project intends to distribute all the functionality that
>comes in those DLL files, but until then, at least it can load the ones
>you (if you are like most PC owners in the world) already have.
>
>But since Wine is far from an independent OS (relying instead on native
>facilities of X11 and Unix), I'm pretty sure it doesn't care about
>OS-ish details like the physical use of FAT filesystems. So try
>copying some or all of C:\WINDOZE\SYSTEM\*.DLL to somewhere in Unixland
>and point Wine at them; then I think you can probably reclaim your
>Windoze partition.
>
>--
>Peter Samuelson
><sampo.creighton.edu!psamuels>
I will definately try this! (if I kill the w-98 partition,a nd wine fails,
I've still won, I get my 800 mb back. If I get wine going, I can play some
of the games I have allready sunk money into. this is good...:)
--
Jim Richardson
Anarchist, pagan and proud of it
WWW.eskimo.com/~warlock
Linux, because life's too short for a buggy OS.
------------------------------
From: Peter Ross <[EMAIL PROTECTED]>
Subject: Re: pre8, modules and problem with aha152x
Date: 22 Jan 1999 15:47:40 +1100
Try the following,
1) login as root.
2) Do your isapnp setup.
3) insmod aha152x aha152x=0x340,9
4) insmod sg
5) run your scanner software.
Hopefully the above should work. It looks like your problem is that
you weren't passing the module parameters correctly. Don't worry it
took me a couple of months to figure that out in my case. I ended up
just compiling the module as a permanent part of the kernel.
Also if you want to use the modprobe method of installing the adapter,
then I think your options line should be
options aha152x aha152x=0x340,9
Finally you should no longer have scsi_mod in the 2.2.x series of
kernels. Well at least I don't have it.
Hope this helps.
Pete.
David Ronis <[EMAIL PROTECTED]> writes:
>I've been running 2.2.0-pre8 on a 586 for a few days. Today I tried
>installing an adaptec aha1520B scsi card in order to try using a
>scanner supposedly supported by sane. The card can be run as a pnp
>card, and it and the scanner (a umax) are recongised at boot time. I
>use isapnp to configure the card, basically to use irq 9, ioport
>0x340, and this seems to work. Unfortunately nothing indicates that
>the card is really seen.
>I configured all the scsi support as modules in the kernel and have
>added the single line:
>alias scsi_hostadapter aha152x
>to /etc/modules.txt. Sane has a tool that searches for scsi
>scanners--it doesn't find one, and afterwards lsmod shows sg and
>scsi_mod as installed, but not aha15x. dmesg gives: scsi : 0 hosts.
>Clearly I've not configured something right--shouldn't I have to tell
>aha152x about the scsi card? I looked at the source code, and it
>suggests giving LILO some flags that sound like what I'm missing,
>however, after trying these nothing changed. I also tried adding a
>line to modules.conf like
>options aha152x 0x340,9
>but this simply caused the find-scanner program to hang.
>Finally, here's what cat /proc/interrupts and ioports gives:
> CPU0
> 0: 411947 XT-PIC timer
> 1: 2 XT-PIC keyboard
> 2: 0 XT-PIC cascade
> 4: 2 XT-PIC serial
> 10: 22881 XT-PIC WD8013
> 13: 1 XT-PIC fpu
> 14: 49112 XT-PIC ide0
> 15: 36 XT-PIC ide1
>NMI: 0
>and
>0000-001f : dma1
>0020-003f : pic1
>0040-005f : timer
>0060-006f : keyboard
>0080-008f : dma page reg
>00a0-00bf : pic2
>00c0-00df : dma2
>00f0-00ff : fpu
>0170-0177 : ide1
>01f0-01f7 : ide0
>02f8-02ff : serial(auto)
>0300-031f : WD8013
>0376-0376 : ide1
>03c0-03df : vga+
>03f6-03f6 : ide0
>03f8-03ff : serial(auto)
>Any help would be most appreciated
>David Ronis
--
+----------------------------------------------------------------------+
| Peter Ross M Sci/Eng Melbourne Uni (change - to . for email) |
| email: [EMAIL PROTECTED] WWW: http://www.cs.mu.oz.au/~petdr |
+----------------------------------------------------------------------+
------------------------------
Date: Wed, 20 Jan 1999 23:36:45 -0500
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.setup
Subject: Packages problem
Can somebody help me in installing the kernel sources on my machine from
RedHat Linux 5.1 distribution ? I have the CDs but face a strange
problem.
I wanted to install PPP and so wanted to build kernel. I had to install
the
Kernel-Sources package.
But when I invoked 'glint' and chose 'Available' button it started
reading the
CD (1) and it encountered the following error.
Glint Graphical Package Manager -- version 2.5
Copyright (C) 1998 - Red Hat Software
This may be freely redistributed under the terms of the GNU Public
License
Traceback (innermost last):
File "/var/tmp/python-root/usr/lib/python1.5/lib-tk/Tkinter.py", line
752, in __call__
return apply(self.func, args)
File "./glint.py", line 62, in available
availablePackageSet = PackagePathSet(currentPackagePath)
File "./packageset.py", line 157, in __init__
self.setPath(path)
File "./packageset.py", line 148, in setPath
self.addPackage(package)
File "./packageset.py", line 40, in addPackage
self.packages[package.getLabel()] = package
File "./package.py", line 138, in getLabel
return (self.getName() + ":" + self.getVersion() + ":" +
File "./package.py", line 116, in getName
return self.h[rpm.RPMTAG_NAME]
AttributeError: h
Thanks,
Karunakar.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: How can I build a Linux system from scratch - NO distribution?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Jan 1999 05:17:50 GMT
On Wed, 20 Jan 1999 10:43:14 -0600, Thomas T. Veldhouse
<[EMAIL PROTECTED]> wrote:
>I would like to build a Linux system from scratch, without using a premade
>distribution as a starting point. I don't know exactly where to begin.
>
>I would like the glibc2 libraries as a base. I would need the the gnu
>development tools and the sysvinit. However, how do I create the partitions
>and get things in place without installing a distribution of linux in the
>first place (and thus all the extra bagage I don't want). I would like to
>create a system similar to the way FreeBSD does things. Install a very lean
>base system with just the development tool required to build the system.
>Everything else is a port which can be installed from source. I love the
>FreeBSD system of ports, but I would like to base my system on Linux.
>
>Is there a way to put a minimal system together on my hard drive (multiple
>ext2 partitions) and get the tools on to it so that I can build what I need
>from there?
You may want to look at one of the "minimalist" systems such as <ULink
URL= "http://beast.delanet.com/pragma/"> Pragma Linux </ULink>, <ULink
URL= "http://www.nomadlinux.com/"> NoMad Linux, </Ulink> or one of the
"router" systems like <Ulink url= "http://www.trinux.org/"> Trinux.
</Ulink> There are probably some other "router-on-a-disk" options; just
add LILO and you should have a tiny, bootable system.
It's obviously a lot of work to replicate the sets of tools available
"almost for free" (in terms of effort requirements) with RPM and dpkg;
it would be quite interesting to see a Linux distribution that used
Ports as its basic "package tool."
>Also, as a side note, do you thing that using GNU inetutils would be a
>good choice for [some of] my networking daemons?
You might want to have a chat with the Debian Hurd folk; they're trying
to put together a distribution that uses Hurd as the "kernel" (which
isn't precisely correct, but close enough to be understood), and *can't*
use the highly-Linux-specific Netkit. They're trying to assess how
usable GNU inetutils is with Hurd; it's obviously nicest if it is highly
compatible with Linux as well.
--
The real problem with the the year 2000 is that there are too many zero
bits and that adversely affects the global bit density. -- Boyd Roberts
<[EMAIL PROTECTED]>
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/linux.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Linux Phase 2: A Consumer Operating System
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Jan 1999 05:17:57 GMT
On Wed, 20 Jan 1999 14:45:28 -0500, Rick Onanian
<[EMAIL PROTECTED]> wrote:
>Christopher Browne wrote:
>> Note that if things change such that these changes really do take place,
>> this will make Linux a much less interesting platform for the people
>> that are interested in "playing with an OS" for its own sake.
>>
>> With the result that many of the sorts of folk that made Linux grow into
>> what it has become are liable to migrate off to other systems that
>> permit them to "play" again. Whether that's Hurd, Xos, FluxOS, *BSD, or
>> whatever.
>>
>> At that point, Linux starts to die. It may continue on for years, but
>> if the sources of innovation leave, that causes great injury.
>
>This result is not required. Noone is required to kill Slackware, or Debian, or your
>favorite distribution. I would envision a new distribution set up commercially
>similar
>to...well...Microsoft. :) Granted, if one does this, than most other distributions
>will
>want to follow, but I think that basically, it will still be as play-with-able as it
>was
>before.
The point is that if interesting pieces of the system "solidify" to the
point that people can't change them without causing immense breakage,
then it's no longer fun playing with those pieces.
At some point, it becomes more difficult to get a change in than it is
to say "Screw it, I'm using another system where I can do what I like,
and have a bit more control."
We can see a certain degree of "ossification" taking place already with
the Linux kernel. It used to be about a year between major new even
versions. The "time betweeen releases" is increasing. And there are
enough big plans coming up in the 2.3 series to give ample opportunity
for it to be 2001 or later until a 2.4 release.
Someone who wants quicker response on some of the stuff that's presently
"pie in the sky" may well find it more productive to play with one of
the other options.
I didn't say that suddenly everyone would take away all the CDs, and
that you'd be left with nothing to run your RC5 cracker on.
The point was that the sorts of people that can build a system like
Linux may conclude it time to move on, which will mean that a great
creative element is taken away. It might be several years before
effects become really apparent.
--
"Windows95, Word97, Office98: With all the criticisms of Microsoft, at
least they include ``best-before'' dating on many of their products..."
-- [EMAIL PROTECTED]
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
Date: Thu, 21 Jan 1999 22:26:59 -0800
From: Kenneth Porter <[EMAIL PROTECTED]>
Subject: Re: How to tell current kernel config?
J.M. Paden wrote:
>
> "Tim Underwood" <[EMAIL PROTECTED]> wrote:
>
> >I want to recompile the kernel, but want to keep the same options as are
> >currently set in the kernel I am using now (RH 5.2 install). How can I tell
> >what options the current kernel has been compiled with?
> >
> >
> Make a copy of the current kernel ".config" file located in
> usr/src/linux/. Note this is a "dotfile" or one that
> begins with a period. You should copy this file
> because a later step of "make mrproper" will
> delete this ".config" file.
This is good if the kernel was built locally. My problem is slightly
different. I downloaded a pre-built kernel from American Megatrends
(ftp://www.megatrends.com) to support a system running on one of their
RAID controllers. I'd now like to build a tuned kernel but using theirs
as a template. Alas, no .config was included with their patch. Is there
any way to ask the kernel what it has?
Ken
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: Obtaining MAC address from remote computer
Date: Thu, 14 Jan 1999 18:41:44 GMT
Sander Pilon wrote:
>
> I dont WANT the ethernet card MAC address.
> I want a *COMPLETELY* transparant forwarder/NAT-device.
>
> Meaning I want to send out packets with other machines MAC addresses.
>
> Regards,
>
> Sander
>
> Dave Hearn wrote in message <77ks28$9ji$[EMAIL PROTECTED]>...
> >Err - your ethernet card will insert the mac stuff for you
> >
> >
> >Sander Pilon wrote in message <77kljl$aom$[EMAIL PROTECTED]>...
> >
> >>
> >>Maybe I should've mentioned I want to do this in C on a per-packet basis.
> >>
> >>A packet arrived on eth0, I'm going to forward it to eth1 and I have to
> >>insert a new MAC
> >>address.
> >>
You may want to freshen your table using the ARP protocol to request the
ethernet address of everyone on your segment. More detail on ARP can
be found in
"Unix Network Programming" by Richard Stevens
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: INT13 disk driver
Date: 22 Jan 1999 10:59:01 +0100
In article <788s82$kha$[EMAIL PROTECTED]>,
Frank T. Lofaro <[EMAIL PROTECTED]> wrote:
>
>1. INT 13h has to point to where it needs to be. Linux revectors the
> INTs. You'd need to know where it pointed and use a different INT
> (I believe 13h to be taken for processor exceptions, etc) or change
> and restore it.
>
What happens is that when you do Int13 or any other int you will run the
interrupt code associated with that interrupt in whatever mode the call or
interrupt gate defines. It is then up to that interrupt handler to figure
out what the reason for the interrupt is and distinquise between a hardware
exception or a int13 system call. It then has to change into emulation
mode if required and call the appropriate entry point in the real mode bios.
Sounds complicated: But that is also what win95 and NT does and dosemu
too.
You'll get the same thing happening with hardware interrupts. Here you
also have to make sure that these hardware interrupts don't interfere with
the real linux device drivers and interrupts handlers, and it is important
that any access to the PIC controllers gets intercepted and handled in
software in such a way that the original dos device driver doesn't see
any difference. If the dos programs were allowed to access the PIC
directly it would seriously damage the stability of the linux system.
Villy
------------------------------
** 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 PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
