Linux-Development-Sys Digest #766, Volume #8      Fri, 1 Jun 01 16:13:18 EDT

Contents:
  Re: hash function for ip address (Joern Engel)
  ext2 performance with large directories (jtnews)
  Re: usleep takes to much time ?! (Jeremiah DeWitt Weiner)
  sigsend - which library/header ("Alexander Spanke")
  Re: How to discover File Descriptor leak in programs? ("Anthony Pioli")
  Re: Patching the original RH (7.1) kernel (?) (David Konerding)
  Modifying sound module ("Hugin")
  Logging signal 11? (Joe Pfeiffer)
  Qdisc Question ("Shravan Mahidhara")
  Re: Getting CURRENT load average (Dennis Jenkins)
  Re: Logging signal 11? (Stefan Boresch)
  Re: ext2 performance with large directories
  Re: usleep takes to much time ?!
  [newbie] How can I install my pegas.usb modem under redhat 7.1 ? ("Thomas Turbato")
  Linux IO scalability ("Shirish")
  Programming Modem Voice (Youngert)
  Re: ext2 performance with large directories (jurriaan kalkman)
  Re: ext2 performance with large directories ("Patrick Draper/Austin/Sector 7 USA, 
Inc.")
  Re: environment variable confusion (Eric Taylor)
  Re: Patching the original RH (7.1) kernel (?) (Pete Zaitcev)

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

From: [EMAIL PROTECTED] (Joern Engel)
Subject: Re: hash function for ip address
Date: 1 Jun 2001 13:59:53 GMT
Reply-To: [EMAIL PROTECTED]

> See Knuths ACP for the analysis.

Do you have a link to that. I could not find anything too useful.

Joern

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

From: jtnews <[EMAIL PROTECTED]>
Subject: ext2 performance with large directories
Date: Fri, 01 Jun 2001 14:03:41 GMT

Anyone know how ext2 performance degrades
with large directories?

I'm developing a software program
which stores 100,000 or more files in
one single directory.

Is directory entry lookup based on some
hashing type of scheme? Or is it a linear
lookup?

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

From: Jeremiah DeWitt Weiner <[EMAIL PROTECTED]>
Subject: Re: usleep takes to much time ?!
Date: 1 Jun 2001 14:25:24 GMT

Lars Guesmar <[EMAIL PROTECTED]> wrote:
> Please, can anybody tell me why a usleep(1 usec) takes 20 ms ?
> (Linux 2.4, glibc2.2, gcc 2.95.2)
> How do I get  an exactly 1/1000 sec sleep ?

        Did you read the usleep man page?
"The sleep may be lengthened slightly by any system activity or by the 
time spent processing the call."
        If you really absolutely must have exactly 0.001 seconds sleep time,
you should probably be looking into something realtime-ish...

JDW



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

From: "Alexander Spanke" <[EMAIL PROTECTED]>
Subject: sigsend - which library/header
Date: Fri, 1 Jun 2001 16:28:23 +0200

Hi,

i have a simple question, i programmed a software for SCO UnixWare 2.1.3 and
now it shoul run under Caldera OpenLinux.
So long a can evrything compile, but at two points, i get a error message,
the two points are parts where i use the function sigsend.
Now my question, in which Library or Header File is this function sigsend or
some equal ?

regards
Alex



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

From: "Anthony Pioli" <[EMAIL PROTECTED]>
Subject: Re: How to discover File Descriptor leak in programs?
Date: Fri, 01 Jun 2001 14:58:25 GMT

In article <[EMAIL PROTECTED]>, "Unknown"
<[EMAIL PROTECTED]> wrote:

Yes, /proc/<pid>/fd is a place to look... 

This worked for me in the past to get a "real time" picture for a single process. 

 watch "/bin/ls -l /proc/<your pid here>/fd/ | /usr/bin/wc"

Perhaps you can just run that in separate windows if you dont have too
many processes...

HTH,
Anthony

> Hello,
> 
> We have a system with multiple processes.  The system runs fine
> initially but soon runs out of File Descriptors. One of the process must
> have openned files/scokets without closing them.  How do you find out
> which one is leaking File Descriptors?
> 
> Thanks so much.
> 
> W.

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

From: [EMAIL PROTECTED] (David Konerding)
Crossposted-To: linux.redhat.misc
Subject: Re: Patching the original RH (7.1) kernel (?)
Date: 1 Jun 2001 14:51:39 GMT
Reply-To: [EMAIL PROTECTED]

On Fri, 01 Jun 2001 08:42:41 +0200, Josef Molnar <[EMAIL PROTECTED]> wrote:
> Hi there,
> 
> My question is: is it possible to patch the RedHat kernel source with
> patches downloaded from ftp.kernel.org?

In theory, yes.  Install the Red Hat kernel source RPM (named 
kernel.something.src.rpm),
then go to /usr/src/redhat, edit the SPECS/kernel.spec file to list your patch,
copy your patch into /usr/src/redhat/SOURCES, and then build the kernel binary RPM
using rpm -bb /usr/src/redhat/SPECS/kernel.spec.  If the patch fails to apply cleanly,
you will see it (and the kernel won't build).

(I didn't get all the filenames right in the paragraph above, it is your responsibility
to figure that out).

> If not, is it possible to use the latest kernel from for RH without any
> modifications?

Yes.  Be aware that Red Hat understandably has patched the 2.4.2 kernel rather heavily,
to add features and bug fixes.  This is more or less necessary when you want to produce
a reliable and self-consistent holistic distribution.  For example I've had no end of
hassles using NFS from very recent versions of the kernels that I've compiled myself.
2.4 isn't yet in a stable state yet (and the kernel developers are still dickering
over what the problems are and how to fix them).

Dave

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

From: "Hugin" <[EMAIL PROTECTED]>
Subject: Modifying sound module
Date: Fri, 1 Jun 2001 17:50:12 +0200

Hello,

I've got a laptop with an Ess1371 soundcard. My problem
is that the internal speakers on the laptop wont work. The only
way I can have sound is by connecting external speakers to
the headphones out jack. Is there a way I can modify ess1371.c
or soundcore.c so that the sound instead is redirected to the
internal speakers?

I've read on linux-laptop.net that the internal speakers on some
laptops wont work in linux, due to internal controller chips
specially designed for the current laptop -> Only supported
in windows.

Any input/comment/suggestion on this problem?

Thanks!



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

From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: Logging signal 11?
Date: 01 Jun 2001 09:39:23 -0600

A bit of background -- I have a couple of flaky machines (Gigabyte
GA-5X motherboard, Aladdin V chipset, 550MHz K6-III processors), which
have thrown sig 11s from day one.  Following a tip I received a while
ago, I tried underclocking them 5%, and they now seem to work great.
At any rate, kernel compiles now succeed.

All the same, I'd like to be able to keep an eye on these guys, so I
can know if they start showing wonky behavior again.  Since they
normally fail by just having random apps crash, it would be very
helpful if I could log all sig 11s, and check the log periodically.

So... is there a way?
-- 
Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
Department of Computer Science       FAX   -- (505) 646-1002
New Mexico State University          http://www.cs.nmsu.edu/~pfeiffer
SWNMRSEF:  http://www.nmsu.edu/~scifair

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

From: "Shravan Mahidhara" <[EMAIL PROTECTED]>
Subject: Qdisc Question
Date: Fri, 1 Jun 2001 10:49:13 -0500

Hi,
Can anyone help me out with understanding how the qdisc structure works?When
packets have to be transmitted,they are waiting in a queue of qdisc structs
and they are then passed to the network device,is this correct?
I don't understand the need for a qdisc struct and what it's supposed to be
doing.The packets are handed down the networking stack in a queue of
sk_buffs,right?Where does the qdisc fit in?

Any help would be greatly appreciated.

Thanks,
Shravan

--
==========================================================================
Any man's finest hour - his greatest fulfillment to all he holds dear - is
that moment when he has worked his heart out in a good cause and lies
exhausted in the field of battle - victorious.
- V.L



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

From: Dennis Jenkins <[EMAIL PROTECTED]>
Subject: Re: Getting CURRENT load average
Date: Fri, 01 Jun 2001 11:04:00 -0500

Cameron Kerr wrote:
> 
> Hello, I've been code surfing all afternoon trying to find
> a way to do the following...
> 
> I need to make a program to retrieve the current laod average of the
> system (This is for cluster computing, I want to find the least busiest
> machine). The best I can find is the look at the stats in /proc/loadavg.
> 
> However, the information there is rather undesirable, since its a
> sliding/decaying average over at least 1 minute. I would like it so that
> after the load had gone, the information I am able to give is more
> accurate, rather than having to wait for the load average to dacay.
> 
> Looking at the kernel source, I'm thinking about the best I could do
> would be to write a module or supplement the kernel so that it calculates
> the average over a smaller timeslice, say 5 seconds.


Further more, how does 'top' calculate CPU busy percentage?  I'm going
to consult the source soon, I guess...


> Is this the best way to proceed, or is there something better?
> 
> Thanks in advance,
> --
> Cameron Kerr -- cameron.kerr @ paradise.net.nz
> Praise Slackware, our baud and saviour!

Slackware rules!

-- 
[EMAIL PROTECTED]                           Universal Savings Bank.
Security Administrator, Unix Administrator, Alpha Geek

The three most dangerous things are a programmer with a soldering
iron, a manager who codes, and a user who gets ideas.

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

From: Stefan Boresch <[EMAIL PROTECTED]>
Subject: Re: Logging signal 11?
Date: 01 Jun 2001 18:34:05 +0200


> A bit of background -- I have a couple of flaky machines (Gigabyte
> GA-5X motherboard, Aladdin V chipset, 550MHz K6-III processors), which
> have thrown sig 11s from day one.  Following a tip I received a while
> ago, I tried underclocking them 5%, and they now seem to work great.
> At any rate, kernel compiles now succeed.
> 
> All the same, I'd like to be able to keep an eye on these guys, so I
> can know if they start showing wonky behavior again.  Since they
> normally fail by just having random apps crash, it would be very
> helpful if I could log all sig 11s, and check the log periodically.

I was under the impression that they ended up in the syslog (unless
the Sig11 hangs your machine because it affects a kernel task);
that is from memory on RH 5.x and 6.x machines (fortunately didn't
have any of those guys in a long time); maybe you have to play
with /etc/syslog.conf stuff.

As to the motherboard you mention: I had a hard time with one of
these, first suspecting memory only to realize that the mobo was dying
on me.  Rather than underclocking you should maybe try memtest
(http://reality.sgi.com/cbrady_denver/memtest86/).  Some of the info
on the homepage may help you diagnose the problem; also, there are
kernel patches to avoid spotty memory.  If memtest runs without problems
but you continue to get Sig11 errors, then you may be heading towards
a dying mobo (or processor).

Good luck,

Stefan

-- 
Stefan Boresch
Institute for Theoretical Chemistry and Structural Molecular Biology
University of Vienna, Waehringerstr. 17       A-1090 Vienna, Austria
Phone: -43-1-427752715                        Fax:   -43-1-427752790

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

From: [EMAIL PROTECTED] ()
Subject: Re: ext2 performance with large directories
Date: Fri, 01 Jun 2001 16:50:43 -0000

In article <[EMAIL PROTECTED]>,
jtnews  <[EMAIL PROTECTED]> wrote:

>Anyone know how ext2 performance degrades
>with large directories?
>
>I'm developing a software program
>which stores 100,000 or more files in
>one single directory.
>
>Is directory entry lookup based on some
>hashing type of scheme? Or is it a linear
>lookup?

It's a linear lookup, i.e. it gets very slow.

--
http://www.spinics.net/linux/

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

From: [EMAIL PROTECTED] ()
Subject: Re: usleep takes to much time ?!
Date: Fri, 01 Jun 2001 16:59:13 -0000

In article <9f88kk$sqn$[EMAIL PROTECTED]>,
Jeremiah DeWitt Weiner  <[EMAIL PROTECTED]> wrote:

>       Did you read the usleep man page?
>"The sleep may be lengthened slightly by any system activity or by the 
>time spent processing the call."

The sleep can be lengthened a lot more than "slightly".  The process
becomes ready to run at the end of the sleep but that's no guarantee
that it'll be scheduled.

--
http://www.spinics.net/linux/

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

From: "Thomas Turbato" <(togliquesto)[EMAIL PROTECTED]>
Subject: [newbie] How can I install my pegas.usb modem under redhat 7.1 ?
Date: Fri, 01 Jun 2001 17:06:39 GMT

Help me please!



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

From: "Shirish" <[EMAIL PROTECTED]>
Subject: Linux IO scalability
Date: Fri, 1 Jun 2001 11:22:01 -0700

Does Linux have an IO scalability issue. We here have 25 drives attached to
a server with two fibre controller cards. The max thruput we can arrive at
is around 40MB/s, thats like 5% PCI efficiency. If I have the same
configuration under windows, I can easily do 250~300MB/s using the same HW
configuration. Any clues!!

-s



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

From: Youngert <[EMAIL PROTECTED]>
Subject: Programming Modem Voice
Date: Fri, 01 Jun 2001 18:24:32 GMT

Hi,

I am not sure if this is the right NG to post and ask question regarding 
the above subject.

These days, most 56Kbps modems are V.90 compliance that support 
data/FAX/voice.  What I would like to do is to be able to write a program 
so that it can be used as a voice answering machine.  In order to do so, I 
need to be able to program and access the voice capacity of the modem.  I 
am wondering if anyone out there knows anyone info as well as existing 
applications that manipulate the modem voice capbility.

TIA.

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

From: [EMAIL PROTECTED] (jurriaan kalkman)
Subject: Re: ext2 performance with large directories
Date: 1 Jun 2001 18:41:16 GMT
Reply-To: [EMAIL PROTECTED]

On Fri, 01 Jun 2001 16:50:43 -0000, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> jtnews  <[EMAIL PROTECTED]> wrote:
> 
>>Anyone know how ext2 performance degrades
>>with large directories?
>>
>>I'm developing a software program
>>which stores 100,000 or more files in
>>one single directory.
>>
>>Is directory entry lookup based on some
>>hashing type of scheme? Or is it a linear
>>lookup?
> 
> It's a linear lookup, i.e. it gets very slow.
> 
There are patches floating around the linux-kernel mailinglist to deal
with this problem, but the general consensus seems to be such programs
are shitty and should be avoided. Reiserfs may do better, BTW.

Good luck,
Jurriaan
-- 
I that case, I shall prepare my Turnip Surprise.
And the surprise is?
There's nothing else in it except turnip.
        Baldrick on Haute Cuisine       
GNU/Linux 2.4.5-ac4 SMP/ReiserFS 2x1402 bogomips load av: 0.01 0.01 0.00

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

From: "Patrick Draper/Austin/Sector 7 USA, Inc." <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: ext2 performance with large directories
Date: Fri, 01 Jun 2001 19:02:06 GMT


A typical solution is to break up the directory into a large tree. The
directories are named according to the files contained inside them.

example:

all files wil names starting with 'a' go into /a. Same with other
letters. If that doesn't break it up enough, start going with two
letters, or three letters, in a tree arrangement.

/a
/a/aa
/a/ab
/a/ac
/a/ad
/b
/b/ba
/b/bb

and so on. The reason for the tree is to make it so that no directory
has too many files. Your program would then look at the filename to get
the right path to the file it's looking for. A good way to do it is to
make a function that given a filename, returns the path that you would
expect to find the file in.

To see another example of this, take a look at your terminfo database
which on my Debian system is in /usr/share/terminfo. I have 2139 files
in that heirarchy, which was enough to warrant splitting into the tree.
You should definitely do this if you have 100,000 files.

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

From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: environment variable confusion
Date: Fri, 01 Jun 2001 19:12:57 GMT

Wow, thanks for all the details, I think I see
what is going on now , and I have only
one more question (but first some explanation):

============================
When I grow the environment, the saved stack area  gets
restored in the same place it was, but that now
overlaps the pointers to the env variables since
adding the large env variable results in everything
starting at a lower address. So, the env vector
gets clobbered on my (only partial) stack restore.

I think you are correct that the entire top of
the stack should be saved/restored. But if I do
that, I think I would have to see that environ
got restored as well and I don't know how to
do that for the libc .so library.

It was mentioned that if environ is in the bss
area, then even the .so libraries would use that.
otherwise they would use their own copy. I found
some source code that seems to indicate that
this might not happen

I found this definition in environ.c, but don't undestand
the comment:
========
/* This must be initialized; we cannot have a weak alias into bss.  */
char **__environ = NULL;
weak_alias (__environ, environ)
===========


I stepped getenv  thru with gdb. I found
the address of environ,  in  one of the rw sections of
libc .so dyn library. So, as  mentioned, this must
be a dynamic environ and not in my bss area.

I think my difficulty is that I don't understand how
weak or weak_alias is implemented.

So, the (final?) question is  how does the loader know what value
to initialize this dynamic environ  to?  The correct value seems to be an
attribute of the new process that exec has just setup. But
it's not until a bit later that libc is loaded and that is when
environ comes into existance for libc.So the true value for
environ must be saved somewhere (in the kernel?) while
exec is setting up the environment. Or do I have the order
of this backwards?


Thanks again, as usual the help  in this message board
is fabulous!!




==================================================
Here is what I have been looking at. If there are any
assembler experts out there, maybe someone can
explain how this reference to __environ works.




Here is the beginning of getenv.c
===========================
#ifndef HAVE_GNU_LD
#define __environ environ
#endif

char *
getenv (name)
     const char *name;
{
  size_t len = strlen (name);
  char **ep;
  uint16_t name_start;

  if (__environ == NULL || name[0] == '\0')
    return NULL;
=================================

Here is it disassembled, I can't figure out what
that call to qsort+336 is all about and the use of
ebx. Could that be how environ gets set up?

=============================
Dump of assembler code for function getenv:
0xa006fcd4 <getenv>:    push   %ebp
0xa006fcd5 <getenv+1>:  mov    %esp,%ebp
0xa006fcd7 <getenv+3>:  push   %edi
0xa006fcd8 <getenv+4>:  push   %esi
0xa006fcd9 <getenv+5>:  push   %ebx
0xa006fcda <getenv+6>:  sub    $0xc,%esp

 (this next part I don't understand)

0xa006fcdd <getenv+9>:  call   0xa006fcd0 <qsort+336>
0xa006fce2 <getenv+14>: add    $0xf516a,%ebx

(I think this is the strlen)

0xa006fce8 <getenv+20>: mov    0x8(%ebp),%eax
0xa006fceb <getenv+23>: mov    (%eax),%dl
0xa006fced <getenv+25>: lea    0x1(%eax),%eax
0xa006fcf0 <getenv+28>: test   %dl,%dl
0xa006fcf2 <getenv+30>: jne    0xa006fceb <getenv+23>
(end of strlen)


0xa006fcf4 <getenv+32>: mov    0x8(%ebp),%edx
0xa006fcf7 <getenv+35>: sub    %edx,%eax
0xa006fcf9 <getenv+37>: dec    %eax
0xa006fcfa <getenv+38>: mov    %eax,0xfffffff0(%ebp)

(is this -below- the check for __environ == NULL)

0xa006fcfd <getenv+41>: mov    0x884(%ebx),%eax
0xa006fd03 <getenv+47>: mov    (%eax),%edx
0xa006fd05 <getenv+49>: test   %edx,%edx
0xa006fd07 <getenv+51>: je     0xa006fd58 <getenv+132>

(this -below-  looks like the check for name[0]==0)

0xa006fd09 <getenv+53>: mov    0x8(%ebp),%ecx
0xa006fd0c <getenv+56>: cmpb   $0x0,(%ecx)
0xa006fd0f <getenv+59>: je     0xa006fd58 <getenv+132>


(Here is that call to setup ebx:)

0xa006fcd0 <qsort+336>: mov    (%esp,1),%ebx
0xa006fcd3 <qsort+339>: ret



[EMAIL PROTECTED] wrote:

> In article <[EMAIL PROTECTED]>,
> Eric Taylor  <[EMAIL PROTECTED]> wrote:
>
> [ ... ]
>
> >The change is done in the shell before running the
> >program. The program runs, notices a particular command
> >line argument which tells it to restore itself from a prior
> >saved checkpoint. This technique has been used on
> >a solaris system and  is being ported to linux
> >w/o much change. It does "mostly" work.
>
> I had assumed that you had a separate program that reloaded and restarted
> your application.  Obviously much of what I wrote was not relevant.
>
> >[when the  program starts up, it reads a file written earlier
> >(prior run) to determine what memory to restore. Next 1 or
> >more sbrk's are done, low address dynamic memory is restored from
> >the file  (just above  the code). In
> >this dynamic area is a saved copy of the stack ( only a few k bytes) at
> >the time
> >the checkpoint is written, so the last part is to copy this
> >over top of the current stack - there is a longjmp done after this
> >which has been setup in such a way to get everything back
> >to where it was at the moment of the save, but with a jump
> >to the code that runs after the restore is complete. Lastly,
> >all i/o is reconnected. It's not a general purpose save/restore, so
> >we only worry about things that  our program needs - I didn't write
> >this so I'm not 100% certain of my facts here]
> >
> >
> >So, I am guessing that bash calls setenv to create or modify
> >the environment inside itself, and later when you run a program,
> >the environment is copied out of the bash process and into the
> >new process that bash forked/exec'd
>
> I believe this is correct.
>
> >After looking at the code in the kernel, I see that there is a
> >special copy that assembles the various strings (which might
> >be anywhere in bash's address space) but sort of packs them
> >all in one place so that the program that is forked/execd ends
> >up with them in one contiguous spot at the top of the stack
> >(do I have this right?)
>
> Yes.  The general layout in ascending order is:
>
> argv array
> envv array
> elf parameters for program startup
> argv strings
> envv strings
> [top of stack]
>
> >What I do to recreate the problem is create a variable
> >like this:
> >
> >export XXX=aaabbb
> >export export XXX=abcdef_$XXX
> >
> >(this last one I repeat some number of times)
> >
> >So, I keep growing XXX  a little bigger, and then run the
> >program which tries to restore itself. For a while it works,
> >so I make XXX  bigger and try again. Eventually I get a
> >segment fault inside getenv (called indirectly by some timezone
> >library routine)
> >
> >
> >This all may seem a little fragile, but I am trying to
> >figure out what is going on, so I can make a policy
> >that will allow this to work - like don't change any
> >environment variables prior to a restore - but that
> >may not be feasible, so I need more understanding.
>
> If you restore all of the stack, it shouldn't matter what was in it
> before, except that you must be sure you don't write over the part
> you are using during restoration.
>
> >I do not believe that this program ever references
> >"environ" itself, so as a poster mentioned, the libc
> >.so must have some way to set this up (i guess this
> >is part of what the dynamic loader does although I
> >don't yet understand how it figures out what the
> >value for "environ" should be)
>
> If your program references "environ", it is placed in the .bss area of
> the program (where uninitialized data sits).
>
> If your program doesn't reference it, it appears to be in the .bss area
> of libc.
>
> Assuming that the latter is the case, changing the size of the env-string
> area will likely result in environ pointing at things that aren't pointers.
> If the stack grew slightly, only the first few env entries would vanish.
>
> The conclusion seems to be that either the environment must not change,
> or environ must be restored, by forcing it into the program .bss area.
>
> >I was thinking I might need to have some pad space
> >somewhere. Maybe if I never get larger, only smaller,
> >it would work... I could try starting out with a large
> >variable and make it smaller which could give me room
> >to grow or add some others.
>
> Actually, there seems to be a small amount of unpredictable padding.
> The kernel code seems to force some kind of alignment when it adds the
> elf-parameters.  Since this area is above the env-pointer array, small
> changes in the environment _might_ not have an effect.
>
> >Where this all comes into play, is that it pretty much works
> >if I save and restore on the same system (and don't mess
> >with environment variables). But, for a real
> >robust situation, I actually need to be able to restart on
> >another system (as close to a clone as possible). This way
> >we can be running the same program at various stages
> >on a few processors. So, part of the problem is that
> >the environment of the process can be different on
> >the other system (host name and ip address would
> >be different for ex)
> >
> >BTW, The program is a simulation that
> >can run for weeks and may use nearly 3 gigs of memory. Most of
> >the code resides in a .so file so we can make changes
> >to the program, if necessary, and then do a restart in the middle. But,
> >that is all working, it's only with the environment/stack
> >that I seem to be having trouble with now..
>
> I guess I would suggest adding a reference to environ to the program
> and see whether that fixes this problem.
>
> The other thing I would suggest is to do a fairly large alloca() in the
> restore case, before calling the main restore logic, to ensure that the
> working part of the stack is below the area that will be in use after
> the restoration.
> --
> B. D. Elliott   [EMAIL PROTECTED]


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

From: [EMAIL PROTECTED] (Pete Zaitcev)
Crossposted-To: linux.redhat.misc
Subject: Re: Patching the original RH (7.1) kernel (?)
Date: 1 Jun 2001 19:38:59 GMT

> My question is: is it possible to patch the RedHat kernel source with
> patches downloaded from ftp.kernel.org?

Yes, there is nothing magic about Red Hat kernel and outside
patches can easily be applied. The procedure differs if you
plan to install the result as RPM or not.

Normally I just threat the RH kernel as any other kernel,
so it looks like this:

1. Make sure you have an RPM area. Default in /usr/src is not
accessible to users, so make your own

$ cat .rpmmacros
%_topdir        /q/zaitcev/rpms

2. Get the SRPM and install it
$ rpm -i kernel-2.4.3-2.src.rpm

3. Do "make prep"
$ rpm -bp rpms/SPECS/kernel-2.4.spec

4. Copy the tree somewhere
$ cp -a rpms/BUILS/kernel-2.4.3/linux ksrc/linux-2.4.3-2-patch

5. Patch
$ patch -d ksrc/linux-2.4.3-2-patch -p1 < some_patch.diff

6. make oldconfig, make dep, make bzImage, make modules

7. Install as usual.

If you need to get RPM built, then you have to incorporate patches
into the spec file. It is easy, just edit it where it is, then
do "rpm -bb kernel-2.4.spec"

-- Pete

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


** 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 by posting to the
comp.os.linux.development.system newsgroup.

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

Reply via email to