[gentoo-dev] USE Linux 2.6.x

[gentoo-dev] USE Linux 2.6.x

[Dhruba Bandopadhyay]

Hello

The 2.6.x kernel is picking up a considerable following and since I began
using about eight test versions back I've noticed several packages needing
different configurations depending on whether you are using 2.4 or 2.6.x.

How must a package determine what kernel is system is using?

(1) /usr/src/linux symlink
(2) /usr/src/linux-beta symlink
(3) uname -r
(4) USE="dev-kernel" (see below) ?

Would a USE flag to signal use of 2.6.x be an idea at all?  Given that
2.6.x is nearing completion this use flag may become redundant.  Or it may
continue to be used for the next dev-branches of both 2.4- and 2.6-.

Of the first three points above, I don't see any of them being
particularly reliable.  So I had to wonder about putting the control in
the user's hands.  Just a thought.

With regards

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] USE Linux 2.6.x

[Mike Frysinger]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 334 bytes --]

On Tuesday 21 October 2003 08:48, Dhruba Bandopadhyay wrote:
> How must a package determine what kernel is system is using?

it uses the /usr/src/linux symlink to determine running kernel ... if you 
always have that set to your running kernel, packages should handle it 
correctly (see nvidia-kernel for a good example)
-mike

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[C. Brewer]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 923 bytes --]

On Tuesday 21 October 2003 5:58, Mike Frysinger wrote:
> On Tuesday 21 October 2003 08:48, Dhruba Bandopadhyay wrote:
> > How must a package determine what kernel is system is using?
>
> it uses the /usr/src/linux symlink to determine running kernel ... if you
> always have that set to your running kernel, packages should handle it
> correctly (see nvidia-kernel for a good example)
> -mike

But why do we keep up with the obselete link? I won't go into the rants 
against, as they are many and well documented, straight on back to the Head
Penguin. But if packages were handling it correctly, they wouldn't be using 
the symlink to climb down to the includes. So we still have link climbing 
even though we have the linux-headers package which is supposed to prevent 
just that...  
-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[Thomas de Grenier de Latour]

On Tue, 21 Oct 2003 08:39:54 -0700
"C. Brewer" <cbrewer@stealthaccess.net> wrote:

> On Tuesday 21 October 2003 5:58, Mike Frysinger wrote:
> > On Tuesday 21 October 2003 08:48, Dhruba Bandopadhyay wrote:
> > > How must a package determine what kernel is system is using?
> >
> > it uses the /usr/src/linux symlink to determine running kernel ...

Not exactly the _running_ kernel, but the _target_ kernel.
 
> But why do we keep up with the obselete link? 

Because it is useful to be able to compile modules for a target kernel
that may be different than the running kernel, and a symlink is a
good way to point the target of your choice.

> So we still have link climbing even though we have the linux-headers
> package which is supposed to prevent just that...  

I don't see how system headers are related to modules compilation. The
flameable symlink is the /usr/include/linux, but it's a different issue.
It is something that on some other distros points on kernel includes
from kernel sources, but as you said, on Gentoo, we have a linux-headers
package and a real directory, so we do things the right way.


Now, about /usr/src/linux-beta, I don't neither understand its semantics
or usefulness. Obviously, /usr/src/linux is the way to go also for 2.6
kernels, at least that's what is assumed in modules ebuilds, so I
usually just delete linux-beta or ignore it.

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] USE Linux 2.6.x

[C. Brewer]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2922 bytes --]

On Tuesday 21 October 2003 9:25, Thomas de Grenier de Latour wrote:

> Because it is useful to be able to compile modules for a target kernel
> that may be different than the running kernel, and a symlink is a
> good way to point the target of your choice.

Sure, that's an excellent point, but since the target kernel and the running 
kernel are likely on the same machine, and the current state of modules in 
portage IIRC isn't allowing the duplication of external modules packages, why 
not just be booted into the one you're making modules for? You're gonna end 
up rebooting either way eventually...

> I don't see how system headers are related to modules compilation. The
> flameable symlink is the /usr/include/linux, but it's a different issue.
> It is something that on some other distros points on kernel includes
> from kernel sources, but as you said, on Gentoo, we have a linux-headers
> package and a real directory, so we do things the right way.

The only modules discussion so far, other than what you recently brought up, 
was Mike's example of how the nvidia-modules package determined the running 
kernel. The original question was how does a package(generic) determine the 
running kernel. While I agree that there are some issues with the modules 
packages that should be handled differently, no package that doesn't provide 
modules should care what kernel you're running. But there are still a few 
packages in the tree that are using that /usr/src/linux symlink to get at 
includes (iproute2 until a while back, plex86 indirectly now,fex.) A nice 
solution for the modules packages might be to allow them to slot to the 
kernel version similar to the way you can specify USE, eg. SLOT="2.6.0-test8" 
emerge nvidia-modules and have it install the modules in /lib/${SLOT}/ (keep 
in mind, I have no idea how the nvidia-modules ebuild looks, thats just a 
general example). I also realize the main flameable link was the /usr/
include/{linux|asm} link pointing back to the kernel sources, but to quote 
Linus -
" I would suggest that people who compile new kernels should:
- NOT do so in /usr/src. Leave whatever kernel (probably only the
   header files) that the distribution came with there, but don't touch
   it.

 - compile the kernel in their own home directory, as their very own
   selves. No need to be root to compile the kernel. You need to be root
   to _install_ the kernel, but that's different.

 - not have a single symbolic link in sight (except the one that the
   kernel build itself sets up, namely the "linux/include/asm" symlink
   that is only used for the internal kernel compile itself)"

1,2,3 things that haven't been done yet.. Personally I compile mine in /opt, 
because my /home is pretty full...
-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

> 1,2,3 things that haven't been done yet.. Personally I compile mine in /opt, 
> because my /home is pretty full...

So you move the sources from /usr/src/ to /opt, or you don't use the
various kernel-sources ebuilds?  If you're moving the sources, what
makes /opt better than /usr/src?  

Incidentally, I'm quite glad that /usr/src/linux is the target of a lot
of our ebuilds, since it's fairly common for me to build and install
alsa, pcmcia, and nvidia modules for the kernel I'm about to boot into. 
(Why do I want to build the modules before rebooting? Because that way I
don't have to spend twenty minutes in console mode before I can have
working sound, video, and networking.)

-g2boojum-
-- 
Grant Goodyear <g2boojum@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[C. Brewer]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1562 bytes --]

On Tuesday 21 October 2003 1:15, Grant Goodyear wrote:

> So you move the sources from /usr/src/ to /opt, or you don't use the
> various kernel-sources ebuilds?  If you're moving the sources, what
> makes /opt better than /usr/src?

Actually, I used to rsync the tree to my home dir, but that became tedious and 
time consuming, as well as trying to inject enough stuff to satisfy all the 
virtuals became a headache. So yes, I move the sources to /opt, and it's not 
a "better" thing..but packages dont look for /opt/usr/src/linux-* either. 
Makes it easier to spot an offending package and try to get it fixed/
resolved.

> Incidentally, I'm quite glad that /usr/src/linux is the target of a lot
> of our ebuilds, since it's fairly common for me to build and install
> alsa, pcmcia, and nvidia modules for the kernel I'm about to boot into.
> (Why do I want to build the modules before rebooting? Because that way I
> don't have to spend twenty minutes in console mode before I can have
> working sound, video, and networking.)

Perfectly understandable, if you have that many modules needing built, I'd 
probably want to build it beforehand, also. But for one or two non-critical
packages, it would be easier to be running the kernel they need to go to. But 
as my disclaimer, I did point out a nice selectable interface for choosing 
the target kernel would be preferred over the current symlink solution.   

-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

On Tue, 2003-10-21 at 19:44, C. Brewer wrote:

> The only modules discussion so far, other than what you recently brought up, 
> was Mike's example of how the nvidia-modules package determined the running 
> kernel. The original question was how does a package(generic) determine the 
> running kernel. While I agree that there are some issues with the modules 
> packages that should be handled differently, no package that doesn't provide 
> modules should care what kernel you're running.

IMHO, the original question was 'asked incorreclty'.  Or then out of a
Gentoo point of view.

We generally do not care what kernel is running - sure, we do wonder
what ARCH we running on, but then that we usually set in make.conf :/

For our purpose, we care about the target kernel - ie, what kernel
should we compile this module for, or (and this might be related to
some other comments from you) what kernel should we use for this
broken user-space program that need kernel headers, and not the
generics in /usr/include.

Sure, Linus might not agree with /usr/src/linux, but then it is
known, and as far as I know there is no problems (except your
usual problems which is package specific and would be broken
anyhow if not current headers was there).

Hope I was not too confusing :)


Thanks,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[Spider]

[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

begin  quote
On Tue, 21 Oct 2003 10:44:36 -0700
"C. Brewer" <cbrewer@stealthaccess.net> wrote:

> On Tuesday 21 October 2003 9:25, Thomas de Grenier de Latour wrote:
> 
> > Because it is useful to be able to compile modules for a target
> > kernel
> > that may be different than the running kernel, and a symlink is a
> > good way to point the target of your choice.
> 
> Sure, that's an excellent point, but since the target kernel and the
> running  kernel are likely on the same machine, and the current state
> of modules in  portage IIRC isn't allowing the duplication of external
> modules packages, why  not just be booted into the one you're making
> modules for? You're gonna end  up rebooting either way eventually...


Then fix pcmcia-cs and alsa-driver before you suggest anything. as it
is, my machine won't boot properly without pcmcia-cs -and- alsa, as they
IRQ conflict unless loaded in a certain order.

They are both dependant on the target module, and theres no way in a
gnomes purple hell you are going to get me into a state where I can
reboot first, and then rebuild the modules, only to reboot again so I
have a working boot session.  uh-oh- NO.

And no, you won't get me to emerge it with SLOT="purple-gnomes-2.4.44" 
either, Just because I sat down and got my own kerneltree installed into
usr/src/testkernelwithextraJFSpatches , and then loose my existing ,
working, tried kernelset.



When you get this set to -automagically- detect the target kernel.,
build modules and fix. then ok.

if you want it to depend on the running kernel, erm...  No. theres a few
things already that do so, and that is -BROKEN- behaviour.  I don't even
-HAVE- the sources for my running kernel at most times. What?  No I
don't need them. I shouldn't need to have my sources for the hard
compiled and working copy of 2.4.18-saviour with extra everything that I
know boots all my machines and I have in a .tar stored away for working
order. 

Yes, this thread invoked a lot of hot emotions from my side.


// Spider
  

-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[C. Brewer]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2763 bytes --]

On Tuesday 21 October 2003 3:25, Spider wrote:
> begin  quote

> Then fix pcmcia-cs and alsa-driver before you suggest anything. as it
> is, my machine won't boot properly without pcmcia-cs -and- alsa, as they
> IRQ conflict unless loaded in a certain order.

Excuse me? "I" should fix these?

> They are both dependant on the target module, and theres no way in a
> gnomes purple hell you are going to get me into a state where I can
> reboot first, and then rebuild the modules, only to reboot again so I
> have a working boot session.  uh-oh- NO.

Under those conditions likely not.....

> And no, you won't get me to emerge it with SLOT="purple-gnomes-2.4.44"
> either, Just because I sat down and got my own kerneltree installed into
> usr/src/testkernelwithextraJFSpatches , and then loose my existing ,
> working, tried kernelset.

Okay, this part comes across barely intelligible, but if it helps substitute 
TARGET= for SLOT=.. of course I did point out it was a suggestion, not a 
solution, and you have offered up what counterproposal?

> When you get this set to -automagically- detect the target kernel.,
> build modules and fix. then ok.

Again with the when "i" thing...

> if you want it to depend on the running kernel, erm...  No. theres a few
> things already that do so, and that is -BROKEN- behaviour.  I don't even
> -HAVE- the sources for my running kernel at most times. What?  No I
> don't need them. I shouldn't need to have my sources for the hard
> compiled and working copy of 2.4.18-saviour with extra everything that I
> know boots all my machines and I have in a .tar stored away for working
> order.

"I" don't want to have it depend on a running kernel, or on a symlink, All I 
was saying is that in most cases it'd probably be just easier to boot into a 
running kernel and build your non-essential mod package, I realize that this 
is not always the case.
 
> Yes, this thread invoked a lot of hot emotions from my side.
>
>
> // Spider

Well, guess what? I was pretty pissed off _before_  I saw your mail, so you 
can imagine where I'm at now, especially since I've asked a couple of times 
why this symlink is necessary, when it's highly discouraged. If a package 
needs this symlink, mask it, get it fixed upstream or dont carry it at all 
ffs. I point out the bad ones when I see them, and I atleast proffered a 
suggestion. I was civil when this was a discussion, but turning this into a 
pissing match was sheer stupidity. But I guess I'm just the stupid end user 
with no say, I guess? Atleast when I'm being a prick, I only represent me. 

-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[Chris Smith]

Ok guys, just keep a lid on it.

I think the symlink is the best way of handling the situation. As far as I 
understand it, the symlink used to be there for when glibc was compiled, to 
know what features the kernel supports etc... Since then we have popped out 
"linux-headers" which basically solves this problem, and had you _not_ had to 
compile anything the symlink could point to wherever the hell you wanted.

Now some packages it seems need to find out which kernel they are going to 
have to operate within, and there is no way of finding this out except being 
told (i.e. a symlink to the target kernel to be built for, or some kind of 
variable set before compilation). I honestly think the symlink is the best 
way of doing this and the env variable just complicates things.

The reason kernel modules cannot link to the "linux-headers" sources is 
because they are not the running sources. If linux-headers didnt exist, every 
time your recompiled your kernel you would have to recompile half your system 
(as I understand it).

Also, the reason Linux told people to do all those three steps were because 
that some _broken_ distros were using the /usr/src/linux symlink to build 
glibc against and therefore breaking glibc when the kernel was upgraded. He 
quoted that method because, even though it may not be the best method, it 
works with most (even broken) distros. 

If the /usr/src/linux symlink was not pointing to the current linux sources, 
you would need to merge kernel related packages _after_ reboot. So when you 
are installing you would need to boot into your own kernel to build, say, 
network card drivers. Chicken and egg, cant fetch pcmcia-cs to install your 
network card.

And by the way, the symlink is NOT obsolete, because there has been no better 
method to address this situation.

Thanks,
Chris.
-- 
            It is easier to fix Unix than to live with NT.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] USE Linux 2.6.x

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 22 October 2003 05:44, C. Brewer wrote:
<cut>

> Okay, this part comes across barely intelligible, but if it helps
> substitute TARGET= for SLOT=.. of course I did point out it was a
> suggestion, not a solution, and you have offered up what counterproposal?

<cut>

> "I" don't want to have it depend on a running kernel, or on a symlink, All
> I was saying is that in most cases it'd probably be just easier to boot
> into a running kernel and build your non-essential mod package, I realize
> that this is not always the case.
>
> > Yes, this thread invoked a lot of hot emotions from my side.
> >
> >
> > // Spider
>
> Well, guess what? I was pretty pissed off _before_  I saw your mail, so you
> can imagine where I'm at now, especially since I've asked a couple of times
> why this symlink is necessary, when it's highly discouraged. If a package
> needs this symlink, mask it, get it fixed upstream or dont carry it at all
> ffs. I point out the bad ones when I see them, and I atleast proffered a
> suggestion. I was civil when this was a discussion, but turning this into a
> pissing match was sheer stupidity. But I guess I'm just the stupid end user
> with no say, I guess? Atleast when I'm being a prick, I only represent me.

This symlink is not highly discouraged. It is highly discouraged to use a 
plain kernel tree as source for the /usr/include/linux headers. Those 
symlinks mean problems. It is also discouraged to assume that /usr/src/linux 
points to the RUNNING kernel, those sources can be found by /lib/modules/
`uname -r`/build. However in this case we want a way against which kernel 
modules should be build.

I wonder why you insist on having an awkward, notworking way of doing so. 
Gentoo is about unattended installs. Such an environment variable violates 
it. Further it would break initial installs. When one does an emerge kde 
after system is just merged, it will pull in a kernel source (for alsa), 
however if you don't specify your variable building alsa-driver still fails. 
However the kernel sources automatically install the linux symlink if it did 
not exist yet (but not change it if it did). Of course we could use another 
name/location, but I don't see the point.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/lj0nbKx5DBjWFdsRAtzFAKDkYB87M/SEpLNFl3jriMWlVdmwZgCfabqw
UKDJcY/TghcKTP7NVL24JX0=
=B3yP
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] USE Linux 2.6.x

[C. Brewer]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2185 bytes --]

On Wednesday 22 October 2003 1:17, Paul de Vrieze wrote:


> This symlink is not highly discouraged. It is highly discouraged to use a
> plain kernel tree as source for the /usr/include/linux headers. Those
> symlinks mean problems. It is also discouraged to assume that
> /usr/src/linux points to the RUNNING kernel, those sources can be found by
> /lib/modules/ `uname -r`/build. However in this case we want a way against
> which kernel modules should be build.

Forgive me then. I must've just assumed that when Linus said "you should'nt do 
that" with his package, that was highly discouraged.

> I wonder why you insist on having an awkward, notworking way of doing so.
> Gentoo is about unattended installs. Such an environment variable violates
> it. Further it would break initial installs. When one does an emerge kde
> after system is just merged, it will pull in a kernel source (for alsa),
> however if you don't specify your variable building alsa-driver still
> fails. However the kernel sources automatically install the linux symlink
> if it did not exist yet (but not change it if it did). Of course we could
> use another name/location, but I don't see the point.

Well I did not say my way was a definative answer, merely a suggestion. I 
believe you meant to say the kernel sources ebuild provides that link, which 
Patrick suggested that could be easily put out of date, and Spider suggested 
he might not keep the sources for. But how is my asking the link get dropped
"awkward and notworking"? You just pointed out the link doesn't change if it 
preexists, so the benefit is that your unattended install just dumped your 
modules into the wrong place, when you have it pointing at the wrong kernel.
So if you need to keep changing this link back and forth to suit where the 
modules go, doesn't this become user preference rather than system 
preference?

There is no easy answer to this problem, but it seems nobody want to tackle it 
either( along with multiple versions of the same modules packages.)
-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[Brian Jackson]

On Wednesday 22 October 2003 01:27 pm, C. Brewer wrote:
<snip>
> 
> There is no easy answer to this problem, but it seems nobody want to tackle 
it 
> either( along with multiple versions of the same modules packages.)

I have no desire to comment on the rest of this thread (it's hot enough), but 
I will comment on the assertion that nothing is being done about "multiple 
versions of the same modules packages". The problem is portage doesn't 
support multiple SLOTs of the same version of a package, and it's not trivial 
to add, I've talked with carpaski about this, and a few things have to be 
done before the real work can be done for this, but I am trying to find 
somebody to do the work. So... somebody is working on it, but it'll take time 
just like everything else.

--iggy

> -- 
> Chuck Brewer
> Registered Linux User #284015
> Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.
> 
> 
> 

-- 
Home -- http://www.brianandsara.net
Gentoo -- http://gentoo.brianandsara.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] USE Linux 2.6.x

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1449 bytes --]

On Wednesday 22 October 2003 20:27, C. Brewer wrote:
>
> Well I did not say my way was a definative answer, merely a suggestion. I
> believe you meant to say the kernel sources ebuild provides that link,
> which Patrick suggested that could be easily put out of date, and Spider
> suggested he might not keep the sources for. But how is my asking the link
> get dropped "awkward and notworking"? You just pointed out the link doesn't
> change if it preexists, so the benefit is that your unattended install just
> dumped your modules into the wrong place, when you have it pointing at the
> wrong kernel. So if you need to keep changing this link back and forth to
> suit where the modules go, doesn't this become user preference rather than
> system preference?
>

You need to have the sources anyway to build a module. What is esp. 
problematic is first installs. One should install a kernel before the final 
is finished (the install man). Normally one also wants to install the modules 
for this kernel. Once people have at least one running kernel, they can at 
least fallback to it.

> There is no easy answer to this problem, but it seems nobody want to tackle
> it either( along with multiple versions of the same modules packages.)

This is something that is high on my wishlist (it should even be doable).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[C. Brewer]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 724 bytes --]

On Wednesday 22 October 2003 12:23, Paul de Vrieze wrote:

> You need to have the sources anyway to build a module. What is esp.
> problematic is first installs. One should install a kernel before the final
> is finished (the install man). Normally one also wants to install the
> modules for this kernel. Once people have at least one running kernel, they
> can at least fallback to it.

Truly, it's too bad that external kernel modules couldn't be less dependent on 
the version of the kernel they need to run on, and put them in a separate 
place entirely, to be called by any kernel:(

-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[Spider]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

begin  quote
On Wed, 22 Oct 2003 12:47:35 -0700
"C. Brewer" <cbrewer@stealthaccess.net> wrote:

> Truly, it's too bad that external kernel modules couldn't be less
> dependent on  the version of the kernel they need to run on, and put
> them in a separate  place entirely, to be called by any kernel:(


Well that would require a microkernel architecture, which Linux is not. 
Linux is a macrokernel with support for separate parts, but a module is
extremely tied to the internals of the kernel, and unless Linus has a
big change of mind, it won't change from this either.


//Spider

-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[Spider]

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

begin  quote
On Tue, 21 Oct 2003 20:44:23 -0700
"C. Brewer" <cbrewer@stealthaccess.net> wrote:

> On Tuesday 21 October 2003 3:25, Spider wrote:
> > begin  quote
> 
> > Then fix pcmcia-cs and alsa-driver before you suggest anything. as
> > it is, my machine won't boot properly without pcmcia-cs -and- alsa,
> > as they IRQ conflict unless loaded in a certain order.
 
> Excuse me? "I" should fix these?



Because, they are two of the problematic builds that are affected by
your suggested way of fixing, or breaking, things.   This was not
personally directed at you, but taken out as examples of packages that
can't just depend on "What am I running right now" Because of how they
work.



 
> > And no, you won't get me to emerge it with
> > SLOT="purple-gnomes-2.4.44" either, Just because I sat down and got
> > my own kerneltree installed into 
> > usr/src/testkernelwithextraJFSpatches , and then loose my existing ,
> > working, tried kernelset.
> 
> Okay, this part comes across barely intelligible, but if it helps
> substitute   TARGET= for SLOT=.. of course I did point out it was a
> suggestion, not a  solution, and you have offered up what
> counterproposal?

Curently my counterproposal is to actually have the usr/src/linux
symlink directed at the target kernel, and if that link isn't found,
assume that we want the running kernel instead, and repoint it at
lib/modules/`uname -r`/build

Just because usr/src/linux is a symlink in our case, why is that worse
than following and relying on the /lib/modules/`uname -r`/build
  symlink?  The name?  if that's the case, we could well make the
symlink named "Target" and instead just confuse people more.





> > When you get this set to -automagically- detect the target kernel.,
> > build modules and fix. then ok.
> 
> Again with the when "i" thing...

Yes, I'm of the old school ,  I -assume- that people who suggest a way
of doing things, also have tried it themselves, or are capable of
implementing it.  When you don't have that situation, you get "Designed
by Commite"  solutions that may sound good, but are in fact unworkable.




> But I guess I'm just the stupid end user  with no say, I guess?
> Atleast when I'm being a prick, I only represent me. 

The personal form "i" which I used througout the whole email suggests
that in this case it is my personal opinion.  To assume that it is that 
of a team, whom I've been sent forth to represent, is plain silly. 


And, in my not overly humble opinion, You have just as much to say as
anyone else. Its not about your email address.



//Spider


-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[C. Brewer]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2977 bytes --]

On Wednesday 22 October 2003 3:40, Spider wrote:

> Because, they are two of the problematic builds that are affected by
> your suggested way of fixing, or breaking, things.   This was not
> personally directed at you, but taken out as examples of packages that
> can't just depend on "What am I running right now" Because of how they
> work.

Point taken. But even if I had this magical fix for the situation, I don't 
have need for those packages and my solution would be handicapped thusly.

> Curently my counterproposal is to actually have the usr/src/linux
> symlink directed at the target kernel, and if that link isn't found,
> assume that we want the running kernel instead, and repoint it at
> lib/modules/`uname -r`/build
>
> Just because usr/src/linux is a symlink in our case, why is that worse
> than following and relying on the /lib/modules/`uname -r`/build
>   symlink?  The name?  if that's the case, we could well make the
> symlink named "Target" and instead just confuse people more.

Okay, but your counterproposal would be flawed as well, because as you pointed 
out, you don't always keep your sources, and without those /usr/src/linux 
will point to nothing, as well as the /lib/modules/`uname -r`/build link. So 
what happens when those both fail? Do we fake a dir in /usr/src, so at leats 
one link works?

> Yes, I'm of the old school ,  I -assume- that people who suggest a way
> of doing things, also have tried it themselves, or are capable of
> implementing it.  When you don't have that situation, you get "Designed
> by Commite"  solutions that may sound good, but are in fact unworkable.

But in order to try this myself (if I was capable), I would need to atleast 
account for quite a few pieces of equipment that I don't currently own in 
order to support all posible scenarios, of which I couldn't afford to do, nor 
find storage for. In order to cover the most possible cases, we need "Design 
by Committe" with the people using this equipment.

> The personal form "i" which I used througout the whole email suggests
> that in this case it is my personal opinion.  To assume that it is that
> of a team, whom I've been sent forth to represent, is plain silly.

Regardless of this being your personal opinion, you're still a dev, and when 
devs say "worksforme" it tends to be the end of development and/or 
discussion, personal opinion or not. I don't assume the rest of the dev team 
agrees with you or otherwise. In fact, I'm gonna say most of them probably 
have given little thought to it one way or the other.


> And, in my not overly humble opinion, You have just as much to say as
> anyone else. Its not about your email address.

I've found that I usually have more to say than anyone else, its the getting 
people to relate part I have trouble with:)
-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[Spider]

[-- Attachment #1: Type: text/plain, Size: 2829 bytes --]

begin  quote
On Wed, 22 Oct 2003 11:07:26 -0700
"C. Brewer" <cbrewer@stealthaccess.net> wrote:

> 

> > Curently my counterproposal is to actually have the usr/src/linux
> > symlink directed at the target kernel, and if that link isn't found,
> > assume that we want the running kernel instead, and repoint it at
> > lib/modules/`uname -r`/build
> >
> > Just because usr/src/linux is a symlink in our case, why is that
> > worse
> > than following and relying on the /lib/modules/`uname -r`/build
> >   symlink?  The name?  if that's the case, we could well make the
> > symlink named "Target" and instead just confuse people more.
> 


> Okay, but your counterproposal would be flawed as well, because as you
> pointed  out, you don't always keep your sources, and without those
> /usr/src/linux  will point to nothing, as well as the
> /lib/modules/`uname -r`/build link. So  what happens when those both
> fail? Do we fake a dir in /usr/src, so at leats  one link works?

Considering that if you don't have a target for the modules, you don't
have source for it, it is bound to fail, so that is a non issue in
either case.  However, assuming that running kernel == target kernel is
a flawed idea and principle, as said, machines may not even boot without
adding said modules.




> > Yes, I'm of the old school ,  I -assume- that people who suggest a
> > way
> > of doing things, also have tried it themselves, or are capable of
> > implementing it.  When you don't have that situation, you get
> > "Designed
> > by Commite"  solutions that may sound good, but are in fact
> > unworkable.
> 
> But in order to try this myself (if I was capable), I would need to
> atleast  account for quite a few pieces of equipment that I don't
> currently own in  order to support all posible scenarios, of which I
> couldn't afford to do, nor  find storage for. In order to cover the
> most possible cases, we need "Design  by Committe" with the people
> using this equipment.

Why?   You don't need to own n(n) types of hardware to presume that
drivers built to a kernel may need to be avaiable in order for boot.
Thats a fairly safe presumption for many (pcmcia drivers is a great
example here), and testing to make sure that the idea is safe is merely
about thinking, not even testing to build. 


However, my argument still stands, running kernel should not be the same
as target kernel in any case.  No matter how you solve the situation you
will need a target kernel , even if target == uname -r.

This cuts it down to how to select where the target is, and for this, a
symlink is a very simple way of standardizing it that requires less
cutting into how building works. 


//Spider
  

-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] USE Linux 2.6.x

[Patrick Lauer]

On Wed, 2003-10-22 at 00:25, Spider wrote:
> They are both dependant on the target module, and theres no way in a
> gnomes purple hell you are going to get me into a state where I can
> reboot first, and then rebuild the modules, only to reboot again so I
> have a working boot session.  uh-oh- NO.
Yes, it makes more sense to "precompile" everything beforw a reboot.

> And no, you won't get me to emerge it with SLOT="purple-gnomes-2.4.44" 
> either, Just because I sat down and got my own kerneltree installed into
> usr/src/testkernelwithextraJFSpatches , and then loose my existing ,
> working, tried kernelset.
Even worse:
1) emerge vanilla-sources
2) build kernel
3) emerge -U world a while later

--> Now you're using a kernel that has been compiled from 2.4.19, but
/usr/src/linux either points into the nirvana or to 2.4.22 which you
didn't order, which you do not use at the moment ... 

I'd like to have kernels "sticky" so that they don't get updated unless
told to (and please don't tell me that I should put my kernel into
package.mask, that's not intuitive and leads only to errors)

> When you get this set to -automagically- detect the target kernel.,
> build modules and fix. then ok.
Sometimes a newer kernel won't boot with the same config. I'm still
using 2.4.19 because all the newer kernels ignore at least one pci
device (like the ide controller or network card !?)

> if you want it to depend on the running kernel, erm...  No. theres a few
> things already that do so, and that is -BROKEN- behaviour.  I don't even
> -HAVE- the sources for my running kernel at most times. What?  No I
> don't need them. I shouldn't need to have my sources for the hard
> compiled and working copy of 2.4.18-saviour with extra everything that I
> know boots all my machines and I have in a .tar stored away for working
> order. 
So maybe kernel managment should be user-controllable, i.e. "don't install 
kernels and use -->this one for everything" ?

> Yes, this thread invoked a lot of hot emotions from my side.
/me agrees

Patrick


--
gentoo-dev@gentoo.org mailing list