init/do_mounts.c uses SCHED_YIELD, which seems no longer defined
although grep tells me it's heavily used in non-Intel code. I noted that
yield() is back, defined via an asmlink, so I replaced the SCHED_YIELD and
schedule() loop with a call to yield(). I also include linux/sched.h
which may not have been needed but avoided trying a compile without.
No patch, I'm not sure if defining SCHED_YIELD in sched.h would have
been the better fix, or would even work, but this worked, I built my
initrd file, and it all booted correctly several times (and is up as I
type).
Note of warning to new Redhat users, for some reason /usr/include/linux
is a directory instead of a symbolic link to /usr/src/linux/include/linux,
so changes in includes aren't used. Possibly an artifact of the install on
that system, but something to note.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> init/do_mounts.c uses SCHED_YIELD, which seems no longer defined
> although grep tells me it's heavily used in non-Intel code. I noted that
Fixed in pre2
> Note of warning to new Redhat users, for some reason /usr/include/linux
> is a directory instead of a symbolic link to /usr/src/linux/include/linux,
> so changes in includes aren't used. Possibly an artifact of the install on
> that system, but something to note.
Thats a feature. Its how this is meant to work. The headers with glibc
reflect the interface glibc provides and was compiled to. The ones with
the kernel reflect the kernel. Linus wanted it that way and RH finally
caught up with implementing it properly
On Thu, 4 Apr 2002 18:45:24 -0500 (EST),
Bill Davidsen <[email protected]> wrote:
> Note of warning to new Redhat users, for some reason /usr/include/linux
>is a directory instead of a symbolic link to /usr/src/linux/include/linux,
>so changes in includes aren't used. Possibly an artifact of the install on
>that system, but something to note.
That is the way it is meant to be. /usr/include/{linux,asm} do not
point to some random kernel source, they are _copies_ of the kernel
headers at the time that glibc was built and must not change until you
install a new glibc.
User space applications must not rely on including "current" kernel
headers, you do not know which headers would be available when the app
is installed. If a user space app requires kernel information then it
must have its own headers that contain that data. The app must also
cope with being run on newer or older kernels than it was compiled for,
that is, it must handle version skew between user space and kernel
interfaces. If your design requires a user space application including
"current" kernel headers then your design is broken and you are own
your own.
On Fri, 5 Apr 2002, Keith Owens wrote:
> On Thu, 4 Apr 2002 18:45:24 -0500 (EST),
> Bill Davidsen <[email protected]> wrote:
> > Note of warning to new Redhat users, for some reason /usr/include/linux
> >is a directory instead of a symbolic link to /usr/src/linux/include/linux,
> >so changes in includes aren't used. Possibly an artifact of the install on
> >that system, but something to note.
>
> That is the way it is meant to be. /usr/include/{linux,asm} do not
> point to some random kernel source, they are _copies_ of the kernel
> headers at the time that glibc was built and must not change until you
> install a new glibc.
Then it's a bit odd that RH ships a new kernel-headers RPM (which
contains the /usr/include/{linux,asm} directories) for each kernel
update and glibc still beeing the same, isn't it ?
Regards,
--
Steffen Persvold | Scalable Linux Systems | Try out the world's best
mailto:[email protected] | http://www.scali.com | performing MPI implementation:
Tel: (+47) 2262 8950 | Olaf Helsets vei 6 | - ScaMPI 1.13.8 -
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY | >320MBytes/s and <4uS latency
In article <[email protected]> you wrote:
> Then it's a bit odd that RH ships a new kernel-headers RPM (which
> contains the /usr/include/{linux,asm} directories) for each kernel
> update and glibc still beeing the same, isn't it ?
Yes it is; and we fixed that properly in the current beta. But note
that the updates are minor anyway (between errata the headers don't
actually change in general); and people complain loudly when I exclude the
kernel-headers package.....
On Fri, 5 Apr 2002 [email protected] wrote:
> In article <[email protected]> you wrote:
> > Then it's a bit odd that RH ships a new kernel-headers RPM (which
> > contains the /usr/include/{linux,asm} directories) for each kernel
> > update and glibc still beeing the same, isn't it ?
>
> Yes it is; and we fixed that properly in the current beta. But note
> that the updates are minor anyway (between errata the headers don't
> actually change in general); and people complain loudly when I exclude the
> kernel-headers package.....
Wouldn't it be more logical to have the kernel-headers stuff inside the
glibc-devel package (I guess you have thought about this already...). Why
do people complain if you remove the kernel-headers package ?
Regards,
--
Steffen Persvold | Scalable Linux Systems | Try out the world's best
mailto:[email protected] | http://www.scali.com | performing MPI implementation:
Tel: (+47) 2262 8950 | Olaf Helsets vei 6 | - ScaMPI 1.13.8 -
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY | >320MBytes/s and <4uS latency