Linux-Development-Sys Digest #22, Volume #7 Thu, 5 Aug 99 07:14:11 EDT
Contents:
Re: bzip2 compressed kernel (Preston F. Crow)
Re: GCC Cross Compiling (Philipp Thomas)
Re: Linking for libc5 under libc6 (Philipp Thomas)
Re: refs on building/accessing shared libraries??? (Paul Kimoto)
Re: Problem with compiling vfat in 2.3 kernel (Alexander Viro)
Re: HP CD-RW Supported by RH 6.0? ([EMAIL PROTECTED])
Re: how does "top" work (*puntero_loco)
A message to kernel developers about IPC (root)
Linux 2.2.x has problem? ([EMAIL PROTECTED])
Re: HP CD-RW Supported by RH 6.0? (Richard Scobie)
Re: c++ grammer (David Fox)
Re: address? (Greg Fruth)
squeaks on video activity w/ soundcard ([EMAIL PROTECTED])
Re: bzip2 compressed kernel (Martin Boening)
Re: 2.2.x(?) problem with SO_LINGER... (Andi Kleen)
Re: A message to kernel developers about IPC (Mattias Engdeg�rd)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Preston F. Crow)
Subject: Re: bzip2 compressed kernel
Date: 5 Aug 1999 03:35:03 GMT
[EMAIL PROTECTED] (Horst von Brand) writes:
>On 4 Aug 1999 19:01:54 GMT, Matthias Kilian <[EMAIL PROTECTED]> wrote:
>>Is there anyone who has the time to patch the kernel to use bzip2 instead of
>>gzip compression algorithms? This would be a nice feature for building
>>one-floppy rescue systems.
>Noone. bzip2 needs _at least_ 900Kb to uncompress, and when booting you've
>got the fabled 640Kb to work with, minus whatever BIOS uses, and the memory
>for the bootloader, etc.
I thought the 640K issue was resolved by the bzImage format. [For
those that don't know, bzImage stands for "big"-zImage, and still uses
gzip, not bzip2. You have to use bzImages if your kernel is larger
than 512K, but this breaks on some older hardware, like a P5-90 that I
used to use.]
>I believe somebody did the exercise and it turned out that what you win by
>compressing the kernel you loose by larger uncompressing code :-)
Ahh. Now that's a sound reason not to use it, if it is correct...
On my system, a stripped dynamic lib gzip uses less than 7K less space
than bzip2. Of course, the general purpose dynamic executable may not
correspond directly to a special purpose static loader. Still, it
suggests that bzip2 probably doesn't require too much more code than
gzip. With ever-increasing kernel sizes (especially a non-modular
kernel on a rescue disk), a bzip2-compressed kernel would probably
save space overall.
So the disadvantages of bzip2 compression for the kernel:
* Uses lots of RAM, so it's out for zImages.
* Uses lots of RAM, so it's out for tight-memory systems
(Could easily fail to boot a 2M system.)
* Slower, especially noticable on older systems.
* Larger code size. [How much??? 7K???]
(Note: Wouldn't effect running kernel size, as initialization
code is freed.)
The advantages:
* Reduces space requirements for the kernel, excepting
decompression code.
So it's a bad choice for old hardware and special environments
(embedded systems, palmtops, and such). It looks like a good choice
for standard personal desktop systems (100MHz+, 8MB+), especially for
rescue disks.
If my analysis is on target, then it would be worth investigating
further. If you're lucky, this could be the code to get you into the
Linux CREDITS file.
Note that you can squeeze a lot more onto rescue disks by using
non-standard disk formats with more/larger sectors/track and
tracks/disk, but that adds complexities in copying/creating the disks
and may reduce reliability. That's an issue for another thread. No
wait, that's an issue for some documentation that should be looked up
by those who are interested. :)
--PC
--
Only be careful, and watch yourselves closely so that you do not forget the
things your eyes have seen or let them slip from your heart as long as you
live. Teach them to your children and to their children after them.
Remember the day you stood before the Lord your God... --Deut 4:9-10a
------------------------------
From: [EMAIL PROTECTED] (Philipp Thomas)
Subject: Re: GCC Cross Compiling
Date: Thu, 05 Aug 1999 00:45:11 GMT
On Mon, 2 Aug 1999 15:51:28 -0700, "Paul Lutus" <[EMAIL PROTECTED]>
wrote:
>This would be very difficult. The languages are constructed differently,
Hmmm, another case of "beware of the lurking Lutus" ? Let's see how
many take the bait B-)
Philipp
--
Nothing would please me more than being able to hire ten programmers
and deluge the hobby market with good software.
-- Bill Gates, 1976
------------------------------
From: [EMAIL PROTECTED] (Philipp Thomas)
Subject: Re: Linking for libc5 under libc6
Date: Thu, 05 Aug 1999 00:45:12 GMT
On 3 Aug 1999 20:50:49 GMT, Hugh Sparks <[EMAIL PROTECTED]> wrote:
>I want to link a program for execution
>on a libc5 machine but I'm developing
>under Redhat 6.0 with libc6.
AFAIK (I've never needed this), you have to create a gcc set up as
cross compiler to do such thing *and* you need all the necessary libs
compiled for libc5.
Philipp
--
Nothing would please me more than being able to hire ten programmers
and deluge the hobby market with good software.
-- Bill Gates, 1976
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: refs on building/accessing shared libraries???
Date: 5 Aug 1999 00:58:59 -0500
Reply-To: [EMAIL PROTECTED]
[note: followups reset (for topical reasons)]
In article <7oajn4$[EMAIL PROTECTED]>, Dan Miller wrote:
> I've suddenly discovered that I have to write a shared library of functions
> for someone else to call functions in. I've never written a shared library,
> nor have I even called one (I don't think), and none of my books say
> anything about it.
>
> Is there anyplace that I can find a tutorial on this process, maybe with
> some simple example code so I can try it out?? Alternately, what
> books are good for learning about this?? I have extensive experience
> with C, I just have never written shared libraries or DLLs before.
Please see the GCC-HOWTO
http://metalab.unc.edu/LDP/HOWTO/GCC-HOWTO.html
(particularly section 6).
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: Problem with compiling vfat in 2.3 kernel
Date: 4 Aug 1999 21:26:57 -0400
In article <[EMAIL PROTECTED]>,
David T. Blake <[EMAIL PROTECTED]> wrote:
>VFAT is broken in development kernels.
>If you need working VFAT use older kernels. It doesn't
>compile because a non-compiling VFAT module is better than
>a corrupted one.
Oh, yes. Returning to update_vm_cache() is not an option too - we have
to deal with changed locking on write() and truncate() and since FAT
can't deal with the holes in files... <shudder>
I have more or less working code for the case of 512-bytes sectors and
I'll post it for testing in a day or two, but the bigsectors stuff and
dmsdos will take more than that.
>These issues would be perfectly clear to you if you did as
>you should when using a development kernel - read the kernel
>mailing list and archives. www.kernelnotes.com
<AOL></AOL>
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.misc
Subject: Re: HP CD-RW Supported by RH 6.0?
Date: Thu, 05 Aug 1999 05:29:11 GMT
>
> No, the ide-scsi and IDE stuff work fine together now. Just use LILO
to boot and pass the hdx=ide-scsi and that drive will be a scsi from
then on.
> >
Yes, but HOW, do you pass the "hdx=ide-scsi" to Lilo?
I put the line in the lilo.conf, but whenever I try to run lilo
I get a Syntax error near line 12 in file /etc/lilo.conf
my lilo.conf with LILO version 21
================
boot=/dev/hda1
delay=15
vga=normal
ramdisk=0
verbose=5
image=/boot/vmlinuz
root=/dev/hda1
label=Linux
other=/dev/hda2
table=/dev/hda
label=Win95
hdc=ide-scsi
I thank you...VERY MUCH...in advance if you could provide the answer
to this question.
mark Covington
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (*puntero_loco)
Subject: Re: how does "top" work
Date: Thu, 5 Aug 1999 07:33:52 +0200
El 2 Aug 1999 06:17:59 GMT, Yung-Hsiang Lu <[EMAIL PROTECTED]> escribi�:
|Hi, Everyone,
|
|I am curious how "top" works. How can it find the utilization of CPU
|idle time? Is there a place I can get the source code of top? I
|believe it is not in /usr/src/linux; I did not find it in GNU ftp
|sites either.
|
I don't know exactly how top works, but if you want to know the idle time it's
easy to read the file /proc/stat, the first line is:
cpu 2211 82 673 327450
^^^^ ^^ ^^^ ^^^^^^
user nice sys idle
So you only have to strtokenize it until you reach the idle field of the line.
------------------------------
From: root <[EMAIL PROTECTED]>
Subject: A message to kernel developers about IPC
Date: Thu, 05 Aug 1999 16:52:51 +1000
In order to perform Inter Process Communication (IPC) , applications
need
to agree on a unique IPC identifier in order to connect to a common
resource
of some kind.
Under UNIX systems, this is achieved using a 32 bit integer value known
as the IPC key..
Under NT the unique IPC identifier is an arbituary length (or very long)
text string. I am not an NT advocate so dont flame me.
I think that the 32 bit integer IPC key is not sufficent. Even though a
32
bit number does provide a large number space, It does not provide enough
uniqueness to prevent collisions of IPC keys.
There is no central management of IPC keys, the application programmer
has to effectively invent these Key values at random and hope that no
other application is using these IPC key values.
It is not easily possible to check if an IPC Key value is already used
by another application. You cannot simply check to see if the IPC
resource is already created because it may be created by your own
application or by a foreign application, you just know that it has been
created.
If two applications accidently share a IPC Key then both applications
will exhibit strange interaction effects and probably both applications
will either hang or crash and you wont have any idea why.
Even tough a 32 bit IPC Key does provide some protection for Key
collisions , I would like to see IPC strings addeds to the kernel.
I am prepared to help design/implement such a feature if other
kernel developers think that it is worth while.
Could I have some feedback from kernel developers , is anyone
else worried about IPC Key management.
Regards,
Scott.
------------------------------
From: [EMAIL PROTECTED]
Subject: Linux 2.2.x has problem?
Date: Thu, 05 Aug 1999 16:10:05 +0900
Hello!
I heard about that Linux 2.2.x kernels has memory allocation problem.
Is that true?
thanks!!!
------------------------------
From: Richard Scobie <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: HP CD-RW Supported by RH 6.0?
Date: Thu, 05 Aug 1999 08:17:01 +0000
[EMAIL PROTECTED] wrote:
>
> >
> > No, the ide-scsi and IDE stuff work fine together now. Just use LILO
> to boot and pass the hdx=ide-scsi and that drive will be a scsi from
> then on.
> > >
>
> Yes, but HOW, do you pass the "hdx=ide-scsi" to Lilo?
> I put the line in the lilo.conf, but whenever I try to run lilo
> I get a Syntax error near line 12 in file /etc/lilo.conf
> my lilo.conf with LILO version 21
>
> I thank you...VERY MUCH...in advance if you could provide the answer
> to this question.
>
> mark Covington
> [EMAIL PROTECTED]
Hi Mark,
Possibly the line;
appenrd = "hdc=ide-scsi"
in your lilo.conf, may help.
Regards,
Richard Scobie
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: c++ grammer
Date: 04 Aug 1999 09:52:28 -0700
jievis <[EMAIL PROTECTED]> writes:
> Hi, All:
> Where can I find the grammer for C++ writen in lex( or flex) and yacc
> (or bison),
> Thanks in advance
>
> Jievis
Here is a useful pointer: http://www.empathy.com/pccts/roskind.html
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: [EMAIL PROTECTED] (Greg Fruth)
Subject: Re: address?
Date: 4 Aug 1999 22:03:32 GMT
In article <Pine.SOL.3.95.990802174152.5299A-100000@comp>, Ann Chen
<[EMAIL PROTECTED]> writes:
>
> We are trying to find out where does the Linux operating system reside??
1060 W. Addison Street, Chicago, IL
--
Gregory Fruth ([EMAIL PROTECTED])
------------------------------
Crossposted-To: comp.os.linux.help,comp.os.linux.misc,comp.os.linux.portable
Subject: squeaks on video activity w/ soundcard
From: [EMAIL PROTECTED]
Date: 05 Aug 1999 04:39:39 -0400
I just got a SoundBlaster 16PCI card for my ThinkPad 600E (w/ docking
station), and I've gotten both the OSS/Free and OSS commercial drivers
working with it using the Ensoniq es1371 driver. However, audio is
interrupted by high pitched squeaks and static whenever there is
significant video activity (moving windows around and such). This
sounds like some sort of IRQ conflict. I poked around and found that
it was on IRQ 11, and so was my TNT video card and my Linksys ethernet
card. This is the same IRQ configuration under Windows 98, where it
works perfectly, so I'm a little confused as to why Linux has problems
with shared PCI interrupts, but I attempted to get the soundcard onto
its own interrupt anyway.
This proves to be kind of difficult on a ThinkPad, since you don't get
any IRQ configuration screens in the BIOS like on regular
machines. You have to use the ThinkPad configuration program under
Windows to allocate more IP addresses to the PCI bus for the docking
station. I allocated three extra IRQs for PCI, and now it appears that
the soundcard and the video card are using different IRQs. Yet the
problem persists. Does anyone have any ideas what might be causing
this interference?
------------------------------
From: [EMAIL PROTECTED] (Martin Boening)
Subject: Re: bzip2 compressed kernel
Date: 5 Aug 1999 10:06:08 GMT
Hi there,
[EMAIL PROTECTED] (Horst von Brand) writes:
>On 4 Aug 1999 19:01:54 GMT, Matthias Kilian <[EMAIL PROTECTED]> wrote:
>>Is there anyone who has the time to patch the kernel to use bzip2 instead of
>>gzip compression algorithms? This would be a nice feature for building
>>one-floppy rescue systems.
>Noone. bzip2 needs _at least_ 900Kb to uncompress, and when booting you've
>got the fabled 640Kb to work with, minus whatever BIOS uses, and the memory
>for the bootloader, etc.
>I believe somebody did the exercise and it turned out that what you win by
>compressing the kernel you loose by larger uncompressing code :-)
Huh? Just recently I upgraded the kernel on my K6-III based system to
2.2.10. The system is based on Slackware 4.0.0. Weirdly enough, it barfed
at 'make zlilo' with 'kernel too large - try make bzlilo to use bzip' or
something similar... even though most everything is modularized. Oh, well,
so i did a make bzlilo - and what do you know: the kernel is now compressed
using bzip or at least the bzip algorithm and it boots just fine.
So, unless its all a forgery, Patrick Volkerdinck HAS created bzip-
compressed kernel images.
Best Regards,
Martin
--
Martin Boening, MB3792 | EMail: [EMAIL PROTECTED]
SBS SCN VAS, Otto-Hahn-Ring 6, D-81739 Muenchen (Perlach), Germany
Phone: +49 896 364 2904 FAX: +49 893 365 1031
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: 2.2.x(?) problem with SO_LINGER...
Date: 05 Aug 1999 08:47:37 +0200
cirrus <[EMAIL PROTECTED]> writes:
> I'm not sure if this is the correct place to post something like this. Actually
>I've never posted here before, but here goes..
> While doing some socket programming with a 2.2.6 kernel, I noticed that when
> one sets the SO_LINGER socket option with a corresponding linger struct set as
> linger_struct.l_onoff = 1;
> linger_struct.l_linger = 0;
>
> the packets sent upon close()ing the socket are not what is expected.
> setting the l_onoff to a nonzero and a the l_linger to zero is supposed to
> force the sending of a RST packet to the connected peer upon a close(), thus
> avoiding the TIME_WAIT state. However on kernels 2.2.5, 2.2.6, and 2.2.10
> (the only ones I have tested) the packet sent on closing is a FIN, which begins
> the 4 way FIN/ACK close and takes the end doing the active close into the
> TIME_WAIT state. sorry, for being so verbose, but I wanted to make it clear what was
>happening. tcpdump verifies that the packet sent upon close is a FIN.
>
> I tested the same code on kernel 2.0.37 and everything went as it is supposed
> to. (sent a RST, no time_wait)
> If there is someone else or somewhere else to which this should be said then
> let me know.
> thanks,
I'm not sure where you got your idea on what SO_LINGER is supposed to do from.
SO_LINGER just specifies whether close() should block until the FIN-ACK shakedown
is finished, or if it should be done asynchronously from the user process
(which could lead to lost errors). TIME_WAIT is still involved of course.
In short, 2.2 is correct, also according to the documentation
(manpages-1.24+, socket(7))
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: [EMAIL PROTECTED] (Mattias Engdeg�rd)
Subject: Re: A message to kernel developers about IPC
Date: 5 Aug 99 09:15:06 GMT
In <[EMAIL PROTECTED]> root <[EMAIL PROTECTED]> writes:
>In order to perform Inter Process Communication (IPC) , applications
>need
>to agree on a unique IPC identifier in order to connect to a common
>resource
>of some kind.
>Under UNIX systems, this is achieved using a 32 bit integer value known
>as the IPC key..
You have just found one of several misdesigns of System V IPC.
The BSD equivalents use the file system as their name space. Unix
domain sockets use file descriptors which enables select/poll to work,
in contrast to sysV message queues. Also, sockets and memory mappings
go away when the last process using them exits - you don't have to do
the manual clean-up afterwards. [%]
Also, unix domain sockets to a large extent use the same API as
TCP/UDP sockets, which makes it easier to distribute applications.
Message queues are bound to one computer.
>I think that the 32 bit integer IPC key is not sufficent. Even though a 32
>bit number does provide a large number space, It does not provide enough
>uniqueness to prevent collisions of IPC keys.
There is the ftok(3) hack, but as noted in the man page, it does not
guarantee unique key values.
>Even tough a 32 bit IPC Key does provide some protection for Key
>collisions , I would like to see IPC strings addeds to the kernel.
I don't. SysV IPC should die. If you want to help improving the
situation, help implementing the much more reasonable Posix IPC
instead. (Yes, it uses a string name space. We could use the
file system for it.)
In particular, see what you can do to make shared writable anonymous
memory mappings work; that would take away one of the last reasons to
use SysV shm. (Someone should fix the X11 MIT-SHM extension to use
mmaps, too.).
And making open() work on unix domain sockets would be *cool*, and
could obsolete fifos right away.
---
[%] Most sysV shm implementations seem to accept the trick to remove a
shared memory segment while it is in use, but it doesn't seem to be
guaranteed to work everywhere.
------------------------------
** 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
******************************
