[gentoo-dev] Kernel sources thread

[gentoo-dev] Kernel sources thread

[Joel Konkle-Parker]

As an interested desktop user, I'm curious about the devs' opinions on 
this recent thread in gentoo-user:

http://article.gmane.org/gmane.linux.gentoo.user/89620

It appears that there is evidence that devs think that the 
gentoo-*-sources aren't very high-quality. It seems typical, though, 
that gentoo users will use the gentoo sources.

If this is not correct, which sources should most people use? What do 
the devs think about gentoo-*-sources?


-- 
Joel Konkle-Parker
Webmaster  [Ballsome.com]

E-mail     [jjk3@msstate.edu]


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Grant Goodyear]

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

Joel Konkle-Parker wrote: [Fri Jul 16 2004, 06:30:53PM EDT]
> As an interested desktop user, I'm curious about the devs' opinions on 
> this recent thread in gentoo-user:
> 
> http://article.gmane.org/gmane.linux.gentoo.user/89620

I think it's safe to say that ciaranm is engaging in hyperbole in his
assertion that "Everyone agrees gentoo-sources is full of garbage".  (Or
perhaps he's claiming that pretty much everybody who looks at the
gentoo-* patch set will decide there's at least one patch that doesn't
matter to him or her, and thus is "extraneous garbage"; it seems that
nobody asked him to clarify what he meant.)  In any event, I run
gentoo-sources and gentoo-dev-sources on all of my x86 machines, and in
general I find that when I encounter a broken kernel it's broken in
vanilla- as well.  The converse is not necessarily true, however, as
gentoo-* kernels are often patched w/ bug fixes before they make it into
the vanilla kernel.  (It's worth noting that ciaranm works w/ sparc
hardware, so his experiences may be quite different from mine.)

Best,
g2boojum
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

Re: [gentoo-dev] Kernel sources thread

[Ciaran McCreesh]

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

On Fri, 16 Jul 2004 19:36:46 -0400 Grant Goodyear <g2boojum@gentoo.org>
wrote:
| Joel Konkle-Parker wrote: [Fri Jul 16 2004, 06:30:53PM EDT]
| > As an interested desktop user, I'm curious about the devs' opinions
| > on this recent thread in gentoo-user:
| > 
| > http://article.gmane.org/gmane.linux.gentoo.user/89620
| 
| I think it's safe to say that ciaranm is engaging in hyperbole in his
| assertion that "Everyone agrees gentoo-sources is full of garbage". 

Hm? Not really. That was a direct quote from one of the kernel team.

(Note: if gentoo-sources now includes 2.6.x kernels, that was referring
to the 2.4.x set)

The 2.6.x patchset is a *lot* cleaner. I'm not the only dev who still
has strong objections to at least one of the patches that's included in
there, however.

For reference: gentoo-sources (2.4) rarely worked on either of my x86
boxes. gentoo-dev-sources (2.6) works on both as of 2.6.7. Before then I
had to manually revert a patch to avoid a solid lock before init came
up.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Kernel sources thread

[Greg KH]

On Sat, Jul 17, 2004 at 12:45:15AM +0100, Ciaran McCreesh wrote:
> On Fri, 16 Jul 2004 19:36:46 -0400 Grant Goodyear <g2boojum@gentoo.org>
> wrote:
> | Joel Konkle-Parker wrote: [Fri Jul 16 2004, 06:30:53PM EDT]
> | > As an interested desktop user, I'm curious about the devs' opinions
> | > on this recent thread in gentoo-user:
> | > 
> | > http://article.gmane.org/gmane.linux.gentoo.user/89620
> | 
> | I think it's safe to say that ciaranm is engaging in hyperbole in his
> | assertion that "Everyone agrees gentoo-sources is full of garbage". 
> 
> Hm? Not really. That was a direct quote from one of the kernel team.
> 
> (Note: if gentoo-sources now includes 2.6.x kernels, that was referring
> to the 2.4.x set)
> 
> The 2.6.x patchset is a *lot* cleaner. I'm not the only dev who still
> has strong objections to at least one of the patches that's included in
> there, however.

Which one, supermount?

As of right now, there are only 4 "features" added to the g-d-s kernel
package, all for very good reason.

> For reference: gentoo-sources (2.4) rarely worked on either of my x86
> boxes. gentoo-dev-sources (2.6) works on both as of 2.6.7. Before then I
> had to manually revert a patch to avoid a solid lock before init came
> up.

Before 2.6.7, the g-d-s package was managed by a different developer
than it currently is :)

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Ciaran McCreesh]

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

On Fri, 16 Jul 2004 17:06:20 -0700 Greg KH <gregkh@gentoo.org> wrote:
| > The 2.6.x patchset is a *lot* cleaner. I'm not the only dev who
| > still has strong objections to at least one of the patches that's
| > included in there, however.
| 
| Which one, supermount?

No, supermount is just pointless, since we've got udev and dev.d, but
it's cleanly =Nable and off by default so I doubt many people really
care. The objectionable patch is bootsplash. Chances are everyone's
already heard wesolows' rant about this, and I agree with everything he
says, so I won't repeat it here.

(Incidentally, until recently bootsplash would change the fb code even
when it was disabled, and it screwed thing up enough that I had to
revert the patch.)

| As of right now, there are only 4 "features" added to the g-d-s kernel
| package, all for very good reason.

Is one of those reasons "looking pretty at the expense of hiding the
messages which show why your keyboard isn't working"? :)

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Kernel sources thread

[Dylan Carlson]

On Friday 16 July 2004 8:32 pm, Ciaran McCreesh wrote:

> No, supermount is just pointless, since we've got udev and dev.d, but
> it's cleanly =Nable and off by default so I doubt many people really
> care. The objectionable patch is bootsplash. Chances are everyone's
> already heard wesolows' rant about this, and I agree with everything he
> says, so I won't repeat it here.

Do we have a plan to deprecate devfs or do we plan to support both udev and 
devfs indefinitely?   If we can get some agreement on how profiles should 
be handled in the future (referencing our previous thread on static 
profiles and things like GLEP19), I think it would make sense to 
standardize on udev going forward.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Ciaran McCreesh]

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

[ argh! resend to list this time... yay for inconsistent mailing list
headers and a few strange people who get upset with Cc:s :) ]

On Sun, 18 Jul 2004 13:53:52 -0400 Dylan Carlson <absinthe@gentoo.org>
wrote:
| Do we have a plan to deprecate devfs or do we plan to support both
| udev and devfs indefinitely?   If we can get some agreement on how
| profiles should be handled in the future (referencing our previous
| thread on static profiles and things like GLEP19), I think it would
| make sense to standardize on udev going forward.

Well, that can't happen across the board until 2.6.x works on
everything. OTOH, it'd be nice if we started suggesting udev (without
that wretched tarball hack) for anyone running 2.6.x. Aside from one
rather nasty 64bit-related b0rkage, udev's been doing very nicely.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm



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

Re: [gentoo-dev] Kernel sources thread

[Dylan Carlson]

On Sunday 18 July 2004 2:10 pm, Ciaran McCreesh wrote:

> Well, that can't happen across the board until 2.6.x works on
> everything. OTOH, it'd be nice if we started suggesting udev (without
> that wretched tarball hack) for anyone running 2.6.x. Aside from one
> rather nasty 64bit-related b0rkage, udev's been doing very nicely.

Right.  I didn't mean that as a question of 'where should we be Now', but 
'where do we want to be later'...  it's probably a foregone conclusion 
(with gregkh steering things) that udev is on its way, but perhaps that 
leaves a question mark of where how we will support devfs when that 
happens.

That said, I don't know how many hacks exist in the package tree to add 
udev support.  Supporting both might be trivial, therefore my assumptions 
might be wrong.  

Maybe gregkh can comment on this in detail.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Greg KH]

On Sun, Jul 18, 2004 at 03:18:38PM -0400, Dylan Carlson wrote:
> On Sunday 18 July 2004 2:10 pm, Ciaran McCreesh wrote:
> 
> > Well, that can't happen across the board until 2.6.x works on
> > everything. OTOH, it'd be nice if we started suggesting udev (without
> > that wretched tarball hack) for anyone running 2.6.x. Aside from one
> > rather nasty 64bit-related b0rkage, udev's been doing very nicely.
> 
> Right.  I didn't mean that as a question of 'where should we be Now', but 
> 'where do we want to be later'...  it's probably a foregone conclusion 
> (with gregkh steering things) that udev is on its way, but perhaps that 
> leaves a question mark of where how we will support devfs when that 
> happens.
> 
> That said, I don't know how many hacks exist in the package tree to add 
> udev support.

I don't know of any such "hacks" becides the tarball stuff.  That will
be necessary for a number of different devices over time until we
finally fix up all of the kernel code.  Actually I think we are pretty
much done with all of the patches for this for a while now.  If there
are any missing places (other than the ones listed already in this
thread), please let me know and I'll look into fixing it up.

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Georgi Georgiev]

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

maillog: 18/07/2004-19:10:04(+0100): Ciaran McCreesh types
> [ argh! resend to list this time... yay for inconsistent mailing list
> headers and a few strange people who get upset with Cc:s :) ]
> 
> On Sun, 18 Jul 2004 13:53:52 -0400 Dylan Carlson <absinthe@gentoo.org>
> wrote:
> | Do we have a plan to deprecate devfs or do we plan to support both
> | udev and devfs indefinitely?   If we can get some agreement on how
> | profiles should be handled in the future (referencing our previous
> | thread on static profiles and things like GLEP19), I think it would
> | make sense to standardize on udev going forward.
> 
> Well, that can't happen across the board until 2.6.x works on
> everything. OTOH, it'd be nice if we started suggesting udev (without
> that wretched tarball hack) for anyone running 2.6.x. Aside from one
> rather nasty 64bit-related b0rkage, udev's been doing very nicely.

Regarding the wretched tarball hack. There is a suggestion at
http://bugs.gentoo.org/show_bug.cgi?id=57110 that makes the hack less wretched
and even useful. I didn't dare use it before, but now:

$ tar tjf /lib/udev-state/devices.tar.bz2
MAKEDEV
video/mga_vid0
mga_vid
vmnet0
vmnet1
vmnet2
vmnet3
vmnet4
vmnet5
vmnet6
vmnet7
vmnet8
vmnet9
sndstat
dri/card0

All it needs is attention.

-- 
|    Georgi Georgiev   |  If he should ever change his faith, it'll    |
|     chutz@gg3.net    |  be because he no longer thinks he's God.     |
|   +81(90)6266-1163   |                                               |

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

Re: [gentoo-dev] Kernel sources thread

[Greg KH]

On Mon, Jul 19, 2004 at 06:23:02AM +0900, Georgi Georgiev wrote:
> maillog: 18/07/2004-19:10:04(+0100): Ciaran McCreesh types
> > [ argh! resend to list this time... yay for inconsistent mailing list
> > headers and a few strange people who get upset with Cc:s :) ]
> > 
> > On Sun, 18 Jul 2004 13:53:52 -0400 Dylan Carlson <absinthe@gentoo.org>
> > wrote:
> > | Do we have a plan to deprecate devfs or do we plan to support both
> > | udev and devfs indefinitely?   If we can get some agreement on how
> > | profiles should be handled in the future (referencing our previous
> > | thread on static profiles and things like GLEP19), I think it would
> > | make sense to standardize on udev going forward.
> > 
> > Well, that can't happen across the board until 2.6.x works on
> > everything. OTOH, it'd be nice if we started suggesting udev (without
> > that wretched tarball hack) for anyone running 2.6.x. Aside from one
> > rather nasty 64bit-related b0rkage, udev's been doing very nicely.
> 
> Regarding the wretched tarball hack. There is a suggestion at
> http://bugs.gentoo.org/show_bug.cgi?id=57110 that makes the hack less wretched
> and even useful. I didn't dare use it before, but now:
> 
> $ tar tjf /lib/udev-state/devices.tar.bz2
> MAKEDEV

What is this still needed for?  LSB stuff?

> video/mga_vid0
> mga_vid

Hm, what driver needs these?  These are not in the LANANA documenation
for device nodes.

> vmnet0
> vmnet1
> vmnet2
> vmnet3
> vmnet4
> vmnet5
> vmnet6
> vmnet7
> vmnet8
> vmnet9

I think the vmware package already creates these as my machines somehow
"just work" with udev and vmware today.

> sndstat

Hm, are you sure you need this?  This should just work on the newer 2.6
kernels.

> dri/card0

Ah yes, DRI.  What fun...
Anyway, the dri developers are working on this, so I'm leaving it up to
their very capable hands for now.

> All it needs is attention.

I agree.  Bug me about this if anyone knows of any other device nodes
that they need (and have the hardware for) that udev doesn't currently
create.

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Georgi Georgiev]

maillog: 21/07/2004-01:38:01(-0400): Greg KH types
> > $ tar tjf /lib/udev-state/devices.tar.bz2
> > MAKEDEV
> 
> What is this still needed for?  LSB stuff?
> 
> > video/mga_vid0
> > mga_vid
> 
> Hm, what driver needs these?  These are not in the LANANA documenation
> for device nodes.
> 
> > vmnet0
> > vmnet1
> > vmnet2
> > vmnet3
> > vmnet4
> > vmnet5
> > vmnet6
> > vmnet7
> > vmnet8
> > vmnet9
> 
> I think the vmware package already creates these as my machines somehow
> "just work" with udev and vmware today.
> 
> > sndstat
> 
> Hm, are you sure you need this?  This should just work on the newer 2.6
> kernels.
> 
> > dri/card0
> 
> Ah yes, DRI.  What fun...
> Anyway, the dri developers are working on this, so I'm leaving it up to
> their very capable hands for now.
> 
> > All it needs is attention.
> 
> I agree.  Bug me about this if anyone knows of any other device nodes
> that they need (and have the hardware for) that udev doesn't currently
> create.

Heeey, you didn't read the bug, did you?

It is an enhancement to the current tarball approach. Instead of tarring
everything that's left in /dev on a shutdown, it only tars what is not taken
care of by udev. As an example I listed my tarball -- there isn't a single
device in there that udev knows about. It is possible to easily ignore files
that you don't want. I guess I forgot to add MAKEDEV in the ignore list
together with stdout, stdin, stderr, core, initctl....

Just read the bug if you want more information. Plus I'd very much like to see
some action on it.

About the devices...
- MAKEDEV: just happened to be there, I didn't explicitely request it
- mga_vid: for the mplayer mga_vid driver
- vmware: I am pretty sure it doesn't "just work", or there wouldn't be bugs
  like #54269. Anyway, I'll try the newer ebuild, because the changelog talks
  about "newest any-any";
- sndstat: see MAKEDEV
- dri: if udev knew about it, it wouldn't get added to the tarball; i.e. when
  they fix it, it will disappear.

-- 
\    Georgi Georgiev   \  What is food to one, is to others bitter     \
 /    chutz@gg3.net     / poison. -- Titus Lucretius Carus              /
\   +81(90)6266-1163   \                                               \

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Paul Varner]

On Wed, 2004-07-21 at 00:38, Greg KH wrote:
> On Mon, Jul 19, 2004 at 06:23:02AM +0900, Georgi Georgiev wrote:
> > vmnet0
> > vmnet1
> > vmnet2
> > vmnet3
> > vmnet4
> > vmnet5
> > vmnet6
> > vmnet7
> > vmnet8
> > vmnet9
> 
> I think the vmware package already creates these as my machines somehow
> "just work" with udev and vmware today.
> 

It doesn't work for me.  For now I've hacked the init.d script to create
the required devices at start and to rm them at stop.  Not a clean
solution, but works for me right now.  Every upgrade to vmware, I
comment out the changes and try again so far it hasn't worked. I haven't
filed a bug since it is vmware and I haven't researched the vmware site
yet to see if it should work.

My system info:
garath root # uname -a
Linux garath 2.6.7-gentoo-r11 #1 SMP Thu Jul 15 23:49:04 CDT 2004 i686
Intel(R) Pentium(R) 4 CPU 1.80GHz GenuineIntel GNU/Linux

garath root # emerge -pv vmware-workstation

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] app-emulation/vmware-workstation-4.5.2.8848-r1  0 kB

garath root # emerge -pv udev

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] sys-fs/udev-030  0 kB

garath net # pwd
/sys/class/net
garath net # ls
eth0  lo  vmnet1  vmnet8
garath net # ls eth0
addr_len  address  broadcast  device  driver  features  flags  ifindex 
iflink  mtu  statistics  tx_queue_len  type
garath net # ls vmnet1
addr_len  address  broadcast  features  flags  ifindex  iflink  mtu 
statistics  tx_queue_len  type
garath net # ls vmnet8
addr_len  address  broadcast  features  flags  ifindex  iflink  mtu 
statistics  tx_queue_len  type

I don't see a device entry for vmnet1 or vmnet8

Regards,
Paul
-- 
My Gentoo stuff: http://varnerfamily.org/pvarner/gentoo

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Greg KH]

On Wed, Jul 21, 2004 at 08:29:09AM -0500, Paul Varner wrote:
> 
> garath net # pwd
> /sys/class/net
> garath net # ls
> eth0  lo  vmnet1  vmnet8
> garath net # ls eth0
> addr_len  address  broadcast  device  driver  features  flags  ifindex 
> iflink  mtu  statistics  tx_queue_len  type
> garath net # ls vmnet1
> addr_len  address  broadcast  features  flags  ifindex  iflink  mtu 
> statistics  tx_queue_len  type
> garath net # ls vmnet8
> addr_len  address  broadcast  features  flags  ifindex  iflink  mtu 
> statistics  tx_queue_len  type

Just a hint, the program 'tree' really shows this info a lot better.

> I don't see a device entry for vmnet1 or vmnet8

As vmnet1 and vmnet8 are network devices, I don't see why you would ever
see a device node for them.  You don't have one for eth0 or lo, right? :)

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Paul Varner]

On Thu, 2004-07-22 at 01:55, Greg KH wrote:
> On Wed, Jul 21, 2004 at 08:29:09AM -0500, Paul Varner wrote:
> > 
> > garath net # pwd
> > /sys/class/net
> > garath net # ls
> > eth0  lo  vmnet1  vmnet8
> > garath net # ls eth0
> > addr_len  address  broadcast  device  driver  features  flags  ifindex 
> > iflink  mtu  statistics  tx_queue_len  type
> > garath net # ls vmnet1
> > addr_len  address  broadcast  features  flags  ifindex  iflink  mtu 
> > statistics  tx_queue_len  type
> > garath net # ls vmnet8
> > addr_len  address  broadcast  features  flags  ifindex  iflink  mtu 
> > statistics  tx_queue_len  type
> 
> Just a hint, the program 'tree' really shows this info a lot better.
> 

Which package do I emerge to get 'tree'? I have sysfsutils installed and
it isn't included there.

> > I don't see a device entry for vmnet1 or vmnet8
> 
> As vmnet1 and vmnet8 are network devices, I don't see why you would ever
> see a device node for them.  You don't have one for eth0 or lo, right? :)
> 

Normally, I would completely agree with you.  However, vmnet1 and vmnet8
while being network devices do require a device node.  If the following
nodes don't exist, they don't work!

crw-r--r--  1 root root 119, 0 Jul 24 22:25 /dev/vmnet0
crw-r--r--  1 root root 119, 1 Jul 24 22:25 /dev/vmnet1
crw-r--r--  1 root root 119, 8 Jul 24 22:25 /dev/vmnet8

Finally, just to be clear, this is something for vmware to fix with
their drivers, not the udev developers.  I was just pointing out that
currently vmware doesn't "just work" with a pure udev system.

Regards,
Paul
-- 
My Gentoo stuff: http://varnerfamily.org/pvarner/gentoo

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Ciaran McCreesh]

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

On Sun, 25 Jul 2004 11:14:00 -0500 Paul Varner
<gentoo-dev@varnerfamily.org> wrote:
| Which package do I emerge to get 'tree'? I have sysfsutils installed
| and it isn't included there.

tree

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Kernel sources thread

[Paul Varner]

On Sun, 2004-07-25 at 11:55, Ciaran McCreesh wrote:
> On Sun, 25 Jul 2004 11:14:00 -0500 Paul Varner
> <gentoo-dev@varnerfamily.org> wrote:
> | Which package do I emerge to get 'tree'? I have sysfsutils installed
> | and it isn't included there.
> 
> tree

This is one of those things where I was thinking too much.  Since the
context was udev, I did a search of "udev tree" on Google, that turned
up tree as being part of SuSE's udev package.  So it didn't dawn on me
that app-text/tree was what I was looking for, even with it staring me
in the face!
-- 
My Gentoo stuff: http://varnerfamily.org/pvarner/gentoo

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Chris Gianelloni]

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

On Sun, 2004-07-25 at 12:14, Paul Varner wrote:
> Normally, I would completely agree with you.  However, vmnet1 and vmnet8
> while being network devices do require a device node.  If the following
> nodes don't exist, they don't work!
> 
> crw-r--r--  1 root root 119, 0 Jul 24 22:25 /dev/vmnet0
> crw-r--r--  1 root root 119, 1 Jul 24 22:25 /dev/vmnet1
> crw-r--r--  1 root root 119, 8 Jul 24 22:25 /dev/vmnet8
> 
> Finally, just to be clear, this is something for vmware to fix with
> their drivers, not the udev developers.  I was just pointing out that
> currently vmware doesn't "just work" with a pure udev system.

Bug #54629

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

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

Re: [gentoo-dev] Kernel sources thread

[Donnie Berkholz]

Chris Gianelloni said:
>> Finally, just to be clear, this is something for vmware to fix with
>> their drivers, not the udev developers.  I was just pointing out that
>> currently vmware doesn't "just work" with a pure udev system.
>
> Bug #54629

Wow, a new mirror in Hungary? Awesome! But are you sure this is what you
meant to say?

Donnie



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Georgi Georgiev]

maillog: 26/07/2004-17:25:05(-0400): Donnie Berkholz types
> Chris Gianelloni said:
> >> Finally, just to be clear, this is something for vmware to fix with
> >> their drivers, not the udev developers.  I was just pointing out that
> >> currently vmware doesn't "just work" with a pure udev system.
> >
> > Bug #54629
> 
> Wow, a new mirror in Hungary? Awesome! But are you sure this is what you
> meant to say?

#54269 he meant. Also browse to #57110.

-- 
*)   Georgi Georgiev   *) A dead man cannot bite. -- Gnaeus Pompeius   *)
(*    chutz@gg3.net    (* (Pompey)                                     (*
*)  +81(90)6266-1163   *)                                              *)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Chris Gianelloni]

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

On Mon, 2004-07-26 at 17:25, Donnie Berkholz wrote:
> Chris Gianelloni said:
> >> Finally, just to be clear, this is something for vmware to fix with
> >> their drivers, not the udev developers.  I was just pointing out that
> >> currently vmware doesn't "just work" with a pure udev system.
> >
> > Bug #54629
> 
> Wow, a new mirror in Hungary? Awesome! But are you sure this is what you
> meant to say?
> 

Yeah... #54269, I meant...

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

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

Re: [gentoo-dev] Kernel sources thread

[Chris Gianelloni]

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

On Wed, 2004-07-21 at 01:38, Greg KH wrote:
> > vmnet0
> > vmnet1
> > vmnet2
> > vmnet3
> > vmnet4
> > vmnet5
> > vmnet6
> > vmnet7
> > vmnet8
> > vmnet9
> 
> I think the vmware package already creates these as my machines somehow
> "just work" with udev and vmware today.

I'm pretty sure VMware is not sysfs-aware and only creates the device
nodes at install time.  I may be wrong on that, but I'm pretty sure the
modules don't create nodes themselves, though this might have changed
since the last time I looked.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

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

Re: [gentoo-dev] Kernel sources thread

[Greg KH]

On Sun, Jul 18, 2004 at 07:10:04PM +0100, Ciaran McCreesh wrote:
> [ argh! resend to list this time... yay for inconsistent mailing list
> headers and a few strange people who get upset with Cc:s :) ]
> 
> On Sun, 18 Jul 2004 13:53:52 -0400 Dylan Carlson <absinthe@gentoo.org>
> wrote:
> | Do we have a plan to deprecate devfs or do we plan to support both
> | udev and devfs indefinitely?   If we can get some agreement on how
> | profiles should be handled in the future (referencing our previous
> | thread on static profiles and things like GLEP19), I think it would
> | make sense to standardize on udev going forward.
> 
> Well, that can't happen across the board until 2.6.x works on
> everything. OTOH, it'd be nice if we started suggesting udev (without
> that wretched tarball hack) for anyone running 2.6.x. Aside from one
> rather nasty 64bit-related b0rkage, udev's been doing very nicely.

That b0rkage was really in all arches, it was just that 64bit machines
showed it in a much more apparent manner :)

I hate writing string parsing code in C...

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Travis Tilley]

> Do we have a plan to deprecate devfs or do we plan to support both udev and
> devfs indefinitely?   If we can get some agreement on how profiles should
> be handled in the future (referencing our previous thread on static
> profiles and things like GLEP19), I think it would make sense to
> standardize on udev going forward.

please dont force udev on me... i refuse to use that crap. :|


-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Ciaran McCreesh]

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

On Sun, 18 Jul 2004 18:53:29 -0400 Travis Tilley <lv@gentoo.org> wrote:
| > Do we have a plan to deprecate devfs or do we plan to support both
| > udev and devfs indefinitely?   If we can get some agreement on how
| > profiles should be handled in the future (referencing our previous
| > thread on static profiles and things like GLEP19), I think it would
| > make sense to standardize on udev going forward.
| 
| please dont force udev on me... i refuse to use that crap. :|

Well, unless you write something else yourself, you won't have much
choice once 2.7 comes along...

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Kernel sources thread

[Martin Schlemmer]

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

On Mon, 2004-07-19 at 00:53, Travis Tilley wrote:
> > Do we have a plan to deprecate devfs or do we plan to support both udev and
> > devfs indefinitely?   If we can get some agreement on how profiles should
> > be handled in the future (referencing our previous thread on static
> > profiles and things like GLEP19), I think it would make sense to
> > standardize on udev going forward.
> 
> please dont force udev on me... i refuse to use that crap. :|

Have you tried it lately?  I was also very sceptic, but now it
seems to work the charm.  Also seems like Greg have pretty much
kept my udev rules to simulate near devfs /dev layout which sould
make it easier.

Also, nice feature to create rules like so:

----
$ cat /etc/udev/rules.d/40-dm.rules
KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="mapper/%k", SYMLINK="%c"
----

gives you all sorts of flexibility (moving disks around is less
painful, etc):

---
$ ls /dev/isw0* -l
lrwxrwxrwx  1 root root 11 Jul 18 18:56 /dev/isw0 -> mapper/dm-0
lrwxrwxrwx  1 root root 11 Jul 18 18:56 /dev/isw0p1 -> mapper/dm-1
lrwxrwxrwx  1 root root 11 Jul 18 18:56 /dev/isw0p2 -> mapper/dm-2
lrwxrwxrwx  1 root root 11 Jul 18 18:56 /dev/isw0p3 -> mapper/dm-3
---

The only 'regression' as such, is that trying to open say
/dev/nvidia0 do not load 'nvidia' if you had an alias in
modprobe.conf ...  I have an idea however to 'fix' that, but
I haven't gotten to it yet, and it will require some prodding
in kernel internals =)

-- 

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] Kernel sources thread

[Greg KH]

On Sun, Jul 18, 2004 at 06:53:29PM -0400, Travis Tilley wrote:
> > Do we have a plan to deprecate devfs or do we plan to support both udev and
> > devfs indefinitely?   If we can get some agreement on how profiles should
> > be handled in the future (referencing our previous thread on static
> > profiles and things like GLEP19), I think it would make sense to
> > standardize on udev going forward.
> 
> please dont force udev on me... i refuse to use that crap. :|

I welcome constructive criticism all the time.  This was not it.

If you have _any_ issues with udev, please let the developers and the
linux-hotplug-devel mailing list know about it.  Otherwise it will not
get fixed, and you will never be happy.

Oh, and that reminds me to go make up a "delete devfs" kernel patch to
send off to lkml, just to force the issue :)

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Travis Tilley]

On Wednesday 21 July 2004 01:28 am, Greg KH wrote:
> On Sun, Jul 18, 2004 at 06:53:29PM -0400, Travis Tilley wrote:
> > please dont force udev on me... i refuse to use that crap. :|
>
> I welcome constructive criticism all the time.  This was not it.
>
> If you have _any_ issues with udev, please let the developers and the
> linux-hotplug-devel mailing list know about it.  Otherwise it will not
> get fixed, and you will never be happy.

just dont -force- udev on me and i'll be happy.

> Oh, and that reminds me to go make up a "delete devfs" kernel patch to
> send off to lkml, just to force the issue :)

heh.

-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Travis Tilley]

On Wednesday 21 July 2004 03:24 am, Travis Tilley wrote:
> On Wednesday 21 July 2004 01:28 am, Greg KH wrote:
> > On Sun, Jul 18, 2004 at 06:53:29PM -0400, Travis Tilley wrote:
> > If you have _any_ issues with udev, please let the developers and the
> > linux-hotplug-devel mailing list know about it.  Otherwise it will not
> > get fixed, and you will never be happy.
>
> just dont -force- udev on me and i'll be happy.
>
> > Oh, and that reminds me to go make up a "delete devfs" kernel patch to
> > send off to lkml, just to force the issue :)
>
> heh.

ok, trying to be just a bit more constructive. :)

1) udev is either ready or it isnt. the fact that you need to use a device 
tarball for entries udev doesnt support shows me that it isnt ready. what's 
the point of using a device management system if you're going to just dump a 
bunch of extra dev entries in there anyway? if udev were ready, this wouldnt 
be necessary.

2) 
ayanami portcvs # ldd `which udevd`
        libc.so.6 => /lib/libc.so.6 (0x0000002a9566d000)
        /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
(0x0000002a95556000)
ayanami portcvs # emerge udev -pv | grep static
ayanami portcvs #

having a userspace dev management system seems flaky enough to me to begin 
with, but that's an opinion. having it non-static just means it's easier for 
me to break... usually when i accidentally break glibc or userspace in 
general (dont laugh... i found out the hard way that gcc 3.4 nuked stack 
smashing protection waaay back in the early revisions and it made every 
binary built with hardened gcc 3.3.x break after i recompiled glibc), i can 
just boot with init=/bin/sash or what have you and have things fixed in a 
handful of minutes... in similar situations of accidental breakage that are 
inevitable when you play with gcc/glibc i would like to have working device 
management. :P

i would also like the option to staticly link against a non-glibc c library, 
but that's more of a request than a need.

3) devfs isnt going away any time soon, and there will be people like me who 
dont think it's a good idea to risk bugs for no apparent benefit.

4) it makes sense to keep supporting devfs even after it's ripped out of the 
kernel, which i think isnt until after the /next/ stable kernel series. since 
we still support 2.4 as the default (on a few archs anyways) i think even 
when it is ripped out, people will be using a kernel series that still has it 
for a -while-. if it werent for this tendency to not use the latest stable 
kernel, i wouldnt have had to move the 2.6 linux-headers into their own 
package just to support nptl properly on archs other than amd64.


bah, i've been suckered into installing udev... so i might as well keep it 
until something breaks. i disabled the tarball hack since it was making /dev 
ugly and cluttered... though i admit it seems to be more ready than i thought 
it was. at least for now i can have both and always make devfs mount on 
boot... please dont think seriously about removing support for that. at least 
not until after we all move over to 2.10 anyways. :/

-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Carsten Lohrke]

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

On Wednesday 21 July 2004 12:34, Travis Tilley wrote:
> 3) devfs isnt going away any time soon, and there will be people like me
> who dont think it's a good idea to risk bugs for no apparent benefit.
And me.

The same goes for the kernel; I'll read the 2.6 changelogs and depending on 
what I read I set marks, when to consider to switch (again). My current mark 
is 2.6.10, but this may change, if I still have to read e.g. too much about 
code changes regarding reiserfs. What I'm reading here about "encouraging" 
users to switch to kernel 2.6 and udev sounds not very friendly to 
conservative users.


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/k3FVwbzmvGLSW8RAvu3AKCPRHUCb9myv8/8QZ4JDlFFEt+A7wCeLWcJ
4kIHJp7mmHg96pWn40z/b4k=
=FQk2
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Kernel sources thread

[Duncan]

Carsten Lohrke posted <200407211304.37526.carlo@gentoo.org>, excerpted
below,  on Wed, 21 Jul 2004 13:04:31 +0200:

> I'll read the 2.6 changelogs and depending on what I read I set marks,
> when to consider to switch (again). My current mark is 2.6.10, but this
> may change, if I still have to read e.g. too much about code changes
> regarding reiserfs.

I take it this means you use reiserfs?  I do, for all my partitions.

You don't mention what kernel you are on now, but I'd strongly urge you to
switch to something with data=ordered (2.6.6-rc-something IIRC) support
if you haven't already (straight mainline kernel.org kernel, I'm talking,
here). IMO, it's /well/ worth it.

FWIW, 2.6.8-rc1 added data=journal mode support, I've been told, which may
be of interest to you for its stability, once there's a 2.6.8 full release
anyway, but ordered mode is perfect for my needs, and I'd DEFINITELY
recommend it to anyone using reiserfs, if they haven't switched to a
kernel using it already.

(I've been asked how one switches modes.  The answer at least for ordered
is that it's the default once you have a kernel that supports it.  Look at
the mount messages logged during boot to verify it, as they should say
using ordered mode if they are.  Given how verbose they made the at-boot
fscks (which I run thru a custom grep filter here, to filter out the
"noise"), I'm surprised the ordered thing isn't more obvious, but that may
reflect the fact that the guy that did the reiserfsck stuff isn't the guy
who did the kernel patches.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Kernel sources thread

[Carsten Lohrke]

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

On Thursday 22 July 2004 09:40, Duncan wrote:
> You don't mention what kernel you are on now
I said I'm conservative regarding kernels - 2.4.26

> FWIW, 2.6.8-rc1 added data=journal mode support
And rc2 reverts some of the reiserfs optimizations again...


Carsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/5p8VwbzmvGLSW8RAhI5AJ9gd1VnmfLC27HS8AkH/VHyt2rQowCgpevS
ag2xzQgt1+uQ5Cud8pJsqio=
=iewD
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Georgi Georgiev]

maillog: 21/07/2004-06:34:21(-0400): Travis Tilley types
> bah, i've been suckered into installing udev... so i might as well keep it 
> until something breaks. i disabled the tarball hack since it was making /dev 
> ugly and cluttered... though i admit it seems to be more ready than i thought 
> it was. at least for now i can have both and always make devfs mount on 
> boot... please dont think seriously about removing support for that. at least 
> not until after we all move over to 2.10 anyways. :/

I, too, was reluctant to try udev, until I tried it and figured that it is
good. Most, but a few drivers work with it, and it is only a matter of creating
entries for the few devices that are not supported.

Plus, if you want to automate the process, you can put the devices in the
tarball and "chattr +i" it, so it doesn't get overwritten. Only problem is, I
use reisefs.

I, too, think that the tarball hack is ugly and makes /dev cluttered. However,
http://bugs.gentoo.org/show_bug.cgi?id=57110 solves this problem. I now use the
tarball, and it doesn't clutter my /dev. Take a look at the bug, and if you
like it, post a comment on the bug. I guess this will increase its chances of
getting some attention. As I thought, I am not the only who had a low opinion
of the tarball hack, so more people are likely to benefit from that fix.

-- 
|    Georgi Georgiev   |  God is a comic playing to an audience        |
|     chutz@gg3.net    |  that's afraid to laugh.                      |
|   +81(90)6266-1163   |                                               |

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Greg KH]

On Wed, Jul 21, 2004 at 06:34:21AM -0400, Travis Tilley wrote:
> On Wednesday 21 July 2004 03:24 am, Travis Tilley wrote:
> > On Wednesday 21 July 2004 01:28 am, Greg KH wrote:
> > > On Sun, Jul 18, 2004 at 06:53:29PM -0400, Travis Tilley wrote:
> > > If you have _any_ issues with udev, please let the developers and the
> > > linux-hotplug-devel mailing list know about it.  Otherwise it will not
> > > get fixed, and you will never be happy.
> >
> > just dont -force- udev on me and i'll be happy.
> >
> > > Oh, and that reminds me to go make up a "delete devfs" kernel patch to
> > > send off to lkml, just to force the issue :)
> >
> > heh.
> 
> ok, trying to be just a bit more constructive. :)
> 
> 1) udev is either ready or it isnt.

No.  udev is ready.  It's the fact that the kernel might not be fully
ready, depending on the devices you use.

> the fact that you need to use a device 
> tarball for entries udev doesnt support shows me that it isnt ready.

No, there is no way to support devices that don't have sysfs support.
For some of them (like 3rd party drivers), that will never happen.

> what's 
> the point of using a device management system if you're going to just dump a 
> bunch of extra dev entries in there anyway? if udev were ready, this wouldnt 
> be necessary.

Great, I challenge you to fix this :)
Or at least file bugs for it...

But for me, and all of my machines, that tarball isn't needed at all.
And for 95% of the world, it should work.  It's that last 5% that is
going to take some kernel work to fix, due to the scarcity of the
hardware being used.

> 2) 
> ayanami portcvs # ldd `which udevd`
>         libc.so.6 => /lib/libc.so.6 (0x0000002a9566d000)
>         /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
> (0x0000002a95556000)
> ayanami portcvs # emerge udev -pv | grep static

udev can be built with the included klibc library, which makes this
whole issue moot.  I've been hesitant to change the ebuild to do this,
due to ia64 issues with klibc.  Hopefully the next version of klibc (and
hence udev) should fix this.  Then I'll enable it for everyone.

And, yes, I agree that this is an issue, that's why klibc is there :)

> 3) devfs isnt going away any time soon, and there will be people like me who 
> dont think it's a good idea to risk bugs for no apparent benefit.

devfs is broken, has known bugs, is unmaintained, and has security
issues.  What more do you want?

Oh, and it will go away soon, see my lkml post.

> 4) it makes sense to keep supporting devfs even after it's ripped out of the 
> kernel, which i think isnt until after the /next/ stable kernel series.

The idea of a development/stable kernel series has just changed.  See
the lwn.net writeup of the kernel summit for more information about
this.

> bah, i've been suckered into installing udev... so i might as well keep it 
> until something breaks. i disabled the tarball hack since it was making /dev 
> ugly and cluttered... though i admit it seems to be more ready than i thought 
> it was. at least for now i can have both and always make devfs mount on 
> boot... please dont think seriously about removing support for that. at least 
> not until after we all move over to 2.10 anyways. :/

Good, glad it's working for you :)

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Ciaran McCreesh]

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

On Wed, 21 Jul 2004 14:16:39 -0400 Greg KH <gregkh@gentoo.org> wrote:
| > 2) 
| > ayanami portcvs # ldd `which udevd`
| >         libc.so.6 => /lib/libc.so.6 (0x0000002a9566d000)
| >         /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
| > (0x0000002a95556000)
| > ayanami portcvs # emerge udev -pv | grep static
| 
| udev can be built with the included klibc library, which makes this
| whole issue moot.  I've been hesitant to change the ebuild to do this,
| due to ia64 issues with klibc.  Hopefully the next version of klibc
| (and hence udev) should fix this.  Then I'll enable it for everyone.

Could you USE flag it please? It was screwing up on sparc64 last time I
tried it (a fair while ago now), so we might need to use.mask it.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] Kernel sources thread

[Martin Schlemmer]

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

On Wed, 2004-07-21 at 21:46, Ciaran McCreesh wrote:
> On Wed, 21 Jul 2004 14:16:39 -0400 Greg KH <gregkh@gentoo.org> wrote:
> | > 2) 
> | > ayanami portcvs # ldd `which udevd`
> | >         libc.so.6 => /lib/libc.so.6 (0x0000002a9566d000)
> | >         /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
> | > (0x0000002a95556000)
> | > ayanami portcvs # emerge udev -pv | grep static
> | 
> | udev can be built with the included klibc library, which makes this
> | whole issue moot.  I've been hesitant to change the ebuild to do this,
> | due to ia64 issues with klibc.  Hopefully the next version of klibc
> | (and hence udev) should fix this.  Then I'll enable it for everyone.
> 
> Could you USE flag it please? It was screwing up on sparc64 last time I
> tried it (a fair while ago now), so we might need to use.mask it.

Just do it static for all (against glibc) Greg?  Those who do
initramfs's will anyhow build custom ...


-- 

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] Kernel sources thread

[Greg KH]

On Wed, Jul 21, 2004 at 08:46:48PM +0100, Ciaran McCreesh wrote:
> On Wed, 21 Jul 2004 14:16:39 -0400 Greg KH <gregkh@gentoo.org> wrote:
> | > 2) 
> | > ayanami portcvs # ldd `which udevd`
> | >         libc.so.6 => /lib/libc.so.6 (0x0000002a9566d000)
> | >         /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
> | > (0x0000002a95556000)
> | > ayanami portcvs # emerge udev -pv | grep static
> | 
> | udev can be built with the included klibc library, which makes this
> | whole issue moot.  I've been hesitant to change the ebuild to do this,
> | due to ia64 issues with klibc.  Hopefully the next version of klibc
> | (and hence udev) should fix this.  Then I'll enable it for everyone.
> 
> Could you USE flag it please? It was screwing up on sparc64 last time I
> tried it (a fair while ago now), so we might need to use.mask it.

Yeah, I'll use the "static" USE flag to enable this.  It should now work
just fine on sparc64, or so the klibc author just told me this week.

I'll make this change next release.

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Chris Gianelloni]

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

On Wed, 2004-07-21 at 06:34, Travis Tilley wrote:
> 1) udev is either ready or it isnt. the fact that you need to use a device 
> tarball for entries udev doesnt support shows me that it isnt ready. what's 
> the point of using a device management system if you're going to just dump a 
> bunch of extra dev entries in there anyway? if udev were ready, this wouldnt 
> be necessary.

Most of those drivers are not sysfs-aware and simply have not been
updated by the various authors.  Most of them are non-kernel modules,
such as VMware.

> 3) devfs isnt going away any time soon, and there will be people like me who 
> dont think it's a good idea to risk bugs for no apparent benefit.

Perhaps the next stable kernel version, if what I've been reading holds
true.

> 4) it makes sense to keep supporting devfs even after it's ripped out of the 
> kernel, which i think isnt until after the /next/ stable kernel series. since 
> we still support 2.4 as the default (on a few archs anyways) i think even 
> when it is ripped out, people will be using a kernel series that still has it 
> for a -while-. if it werent for this tendency to not use the latest stable 
> kernel, i wouldnt have had to move the 2.6 linux-headers into their own 
> package just to support nptl properly on archs other than amd64.

Agreed, we will have to maintain support for some time to come.

> bah, i've been suckered into installing udev... so i might as well keep it 
> until something breaks. i disabled the tarball hack since it was making /dev 
> ugly and cluttered... though i admit it seems to be more ready than i thought 
> it was. at least for now i can have both and always make devfs mount on 
> boot... please dont think seriously about removing support for that. at least 
> not until after we all move over to 2.10 anyways. :/

I find the flexibility it gives me to be much better than devfs, and I
enjoy having the "standard" Linux device naming that we're all used to
having from before devfs.  Currently, I use it to create custom /dev/
entries for specific pieces of hardware, like /dev/usbkey and
/dev/archos, along with the "standard" device nodes for those devices,
so I could setup hotplug.d with a script to automatically mount them
upon them being plugged into my machine.  I find it to be far superior
to using devfs+supermount, since there's nothing "fooling" the kernel
into thinking a device is always mounted.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

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

Re: [gentoo-dev] Kernel sources thread

[Martin Schlemmer]

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

On Wed, 2004-07-21 at 22:40, Chris Gianelloni wrote:
> On Wed, 2004-07-21 at 06:34, Travis Tilley wrote:
> > 1) udev is either ready or it isnt. the fact that you need to use a device 
> > tarball for entries udev doesnt support shows me that it isnt ready. what's 
> > the point of using a device management system if you're going to just dump a 
> > bunch of extra dev entries in there anyway? if udev were ready, this wouldnt 
> > be necessary.
> 
> Most of those drivers are not sysfs-aware and simply have not been
> updated by the various authors.  Most of them are non-kernel modules,
> such as VMware.
> 

It really is not that difficult to patch the specific driver for
sysfs - I did it for both nVidia and svgalib ...


-- 

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] Kernel sources thread

[Mike Frysinger]

On Thursday 22 July 2004 03:06 pm, Martin Schlemmer wrote:
> It really is not that difficult to patch the specific driver for
> sysfs - I did it for both nVidia and svgalib ...

i sent the sysfs patch upstream and the svgalib guy had no problem accepting 
it :)
-mike

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] RFC: factoring logic for selection of "safe" gcc -O flags in ebuilds (uclibc users take note)

[Gavin]

Problem
===========
Many ebuilds force gcc to use "-O2" instead of other, possibly viable values.  For example, "-Os" does work in some circumstances for certain ebuilds that currently force the use of "-O2".  Those using uclibc and/or CPUs with small caches might prefer "-Os".  However, maintaining a clone of an ebuild in a portage overlay directory for the sole purpose of changing "replace-flags -O? -O2" to "replace-flags -O? -Os" present users with an unecessary hassle.

Proposed Solution
====================
Are ebuilds the best place to make the decision regarding which optimization is "safe" for the target system?  Perhaps we can factor and encapsulate the logic into flag-o-matic?

As a first step, what if we add 'SAFE_GCC_O_FLAG="-O2"' to /etc/make.globals?  It might be a long time before we could expect everyone using new ebuilds to have a make.global with SAFE_GCC_O_FLAG defined.  Ideally, an appropriate default might be automatically determined, but I want a super simple, first step solution.

/usr/portage/eclass/flag-o-matic.eclass:
# credits to Martin Schlemmer's input (see http://bugs.gentoo.org/show_bug.cgi?id=57223)
replace-with-safe-gcc-o-flag() {
  [ -z "${SAFE_GCC_O_FLAG}" ] && SAFE_GCC_O_FLAG="-O2"
  CFLAGS="${CFLAGS//-O?/ } ${SAFE_GCC_O_FLAG}"
  CXXFLAGS="${CXXFLAGS//-O?/ } ${SAFE_GCC_O_FLAG}"
  export CFLAGS CXXFLAGS
  return 0
}

Alternative (less efficient, but less code):
replace-with-safe-gcc-o-flag() {
  [ -z "${SAFE_GCC_O_FLAG}" ] && SAFE_GCC_O_FLAG="-O2"
  replace-flags -O? ${SAFE_GCC_O_FLAG}"
  return 0
}

# appends SAFE_GCC_O_FLAG to "emerge info" results:
--- /usr/lib/portage/bin/emerge.orig    2004-07-17 09:13:48.690078831 -0700
+++ /usr/lib/portage/bin/emerge 2004-07-17 09:14:08.067093698 -0700
@@ -2314,7 +2314,7 @@
                myvars=['GENTOO_MIRRORS', 'CONFIG_PROTECT', 'CONFIG_PROTECT_MASK',
                                'PORTDIR', 'DISTDIR', 'PKGDIR', 'PORTAGE_TMPDIR', 'PORTDIR_OVERLAY',
                                'USE', 'COMPILER', 'CHOST', 'CFLAGS', 'CXXFLAGS','ACCEPT_KEYWORDS',
-                               'MAKEOPTS', 'AUTOCLEAN', 'SYNC', 'FEATURES']
+                               'MAKEOPTS', 'AUTOCLEAN', 'SYNC', 'FEATURES', 'SAFE_GCC_O_FLAG']
        myvars.sort()
        for x in myvars:
                print x+'="'+portage.settings[x]+'"'


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: factoring logic for selection of "safe" gcc -O flags in ebuilds (uclibc users take note)

[Andrew Ross]

Am I the only one who received this message mixed in the the kernel
sources thread?

I'm guessing not:

"References: <cd9kuv$j9e$1@sea.gmane.org>
         <1090442410.11373.139.camel@localhost>
         <1090523177.10205.14.camel@nosferatu.lan>
         <200407221611.36772.vapier@gentoo.org>"

Cheers

Andrew


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Martin Schlemmer]

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

On Thu, 2004-07-22 at 22:11, Mike Frysinger wrote:
> On Thursday 22 July 2004 03:06 pm, Martin Schlemmer wrote:
> > It really is not that difficult to patch the specific driver for
> > sysfs - I did it for both nVidia and svgalib ...
> 
> i sent the sysfs patch upstream and the svgalib guy had no problem accepting 
> it :)

I sent the first version already - he had some hangups about some of
the 2.6 cleanups, and somewhere inbetween the sysfs bit never got in.
So don't know if you just made a better case, I am too annoyingly
persistant, or maybe he's got something against german surnames =)

-- 

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] Kernel sources thread

[Georgi Georgiev]

maillog: 22/07/2004-21:06:17(+0200): Martin Schlemmer types
> On Wed, 2004-07-21 at 22:40, Chris Gianelloni wrote:
> > On Wed, 2004-07-21 at 06:34, Travis Tilley wrote:
> > > 1) udev is either ready or it isnt. the fact that you need to use a device 
> > > tarball for entries udev doesnt support shows me that it isnt ready. what's 
> > > the point of using a device management system if you're going to just dump a 
> > > bunch of extra dev entries in there anyway? if udev were ready, this wouldnt 
> > > be necessary.
> > 
> > Most of those drivers are not sysfs-aware and simply have not been
> > updated by the various authors.  Most of them are non-kernel modules,
> > such as VMware.
> > 
> 
> It really is not that difficult to patch the specific driver for
> sysfs - I did it for both nVidia and svgalib ...

You did?! Where is the patch? I have nvidia-kernel-1.0.6106, and it is still
not sysfs aware.

-- 
|    Georgi Georgiev   |  I am here by the will of the people and I    |
|     chutz@gg3.net    |  won't leave until I get my raincoat back.    |
|   +81(90)6266-1163   |  - a slogan of the anarchists in Richard      |
|  ------------------- |  Kadrey's "Metrophage"                        |

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Martin Schlemmer]

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

On Fri, 2004-07-23 at 05:31, Georgi Georgiev wrote:
> maillog: 22/07/2004-21:06:17(+0200): Martin Schlemmer types
> > On Wed, 2004-07-21 at 22:40, Chris Gianelloni wrote:
> > > On Wed, 2004-07-21 at 06:34, Travis Tilley wrote:
> > > > 1) udev is either ready or it isnt. the fact that you need to use a device 
> > > > tarball for entries udev doesnt support shows me that it isnt ready. what's 
> > > > the point of using a device management system if you're going to just dump a 
> > > > bunch of extra dev entries in there anyway? if udev were ready, this wouldnt 
> > > > be necessary.
> > > 
> > > Most of those drivers are not sysfs-aware and simply have not been
> > > updated by the various authors.  Most of them are non-kernel modules,
> > > such as VMware.
> > > 
> > 
> > It really is not that difficult to patch the specific driver for
> > sysfs - I did it for both nVidia and svgalib ...
> 
> You did?! Where is the patch? I have nvidia-kernel-1.0.6106, and it is still
> not sysfs aware.

It has been in the last 3 versions I think:

---
 # udevinfo  -d | grep nvidia
P: /class/nvidia/nvidia0
N: nvidia0
P: /class/nvidia/nvidiactl
N: nvidiactl
---

Are you sure you have kernel, etc configure correctly?  Btw,
udev system do not support autoloading of modules, so you
have to add it to /etc/modules.autoload.d/kernel-2.6, but
then the device nodes should be created automatically ...


-- 

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] Kernel sources thread

[Georgi Georgiev]

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

maillog: 24/07/2004-18:27:21(+0200): Martin Schlemmer types
> On Fri, 2004-07-23 at 05:31, Georgi Georgiev wrote:
> > maillog: 22/07/2004-21:06:17(+0200): Martin Schlemmer types
> > > On Wed, 2004-07-21 at 22:40, Chris Gianelloni wrote:
> > > > On Wed, 2004-07-21 at 06:34, Travis Tilley wrote:
> > > > > 1) udev is either ready or it isnt. the fact that you need to use a device 
> > > > > tarball for entries udev doesnt support shows me that it isnt ready. what's 
> > > > > the point of using a device management system if you're going to just dump a 
> > > > > bunch of extra dev entries in there anyway? if udev were ready, this wouldnt 
> > > > > be necessary.
> > > > 
> > > > Most of those drivers are not sysfs-aware and simply have not been
> > > > updated by the various authors.  Most of them are non-kernel modules,
> > > > such as VMware.
> > > > 
> > > 
> > > It really is not that difficult to patch the specific driver for
> > > sysfs - I did it for both nVidia and svgalib ...
> > 
> > You did?! Where is the patch? I have nvidia-kernel-1.0.6106, and it is still
> > not sysfs aware.
> 
> It has been in the last 3 versions I think:
> 
> ---
>  # udevinfo  -d | grep nvidia
> P: /class/nvidia/nvidia0
> N: nvidia0
> P: /class/nvidia/nvidiactl
> N: nvidiactl
> ---
> 
> Are you sure you have kernel, etc configure correctly?  Btw,
> udev system do not support autoloading of modules, so you
> have to add it to /etc/modules.autoload.d/kernel-2.6, but
> then the device nodes should be created automatically ...

No such thing here. The nvidia module is loaded (I even reloaded it), the
version is 1.0.6106, and there is nothing related to nvidia in /sys/class/.

I am using the KBUILD_OUTPUT feature of my kernel. Could it be related?  Should
I take this to bugs.gentoo.org?

-- 
\    Georgi Georgiev   \  Sentient plasmoids are a gas.                \
 /    chutz@gg3.net     /                                               /
\   +81(90)6266-1163   \                                               \

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

Re: [gentoo-dev] Kernel sources thread

[Norberto Bensa]

> On Fri, 2004-07-23 at 05:31, Georgi Georgiev wrote:
>> You did?! Where is the patch? I have nvidia-kernel-1.0.6106, and it is
>> still
>> not sysfs aware.
>
> Are you sure you have kernel, etc configure correctly?  Btw,
> udev system do not support autoloading of modules, so you
> have to add it to /etc/modules.autoload.d/kernel-2.6, but
> then the device nodes should be created automatically ...

No need for nvidia in /etc/modules.autoload.d/kernel-2.6; my autoload file
is empty, but nvidia comes up when hotplug starts. So the answer seems to
"rc-update add hotplug default" ;)

Best regards,
Norberto


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Georgi Georgiev]

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

maillog: 24/07/2004-18:27:21(+0200): Martin Schlemmer types
> 
> It has been in the last 3 versions I think:
> 
> ---
>  # udevinfo  -d | grep nvidia
> P: /class/nvidia/nvidia0
> N: nvidia0
> P: /class/nvidia/nvidiactl
> N: nvidiactl
> ---
> 
> Are you sure you have kernel, etc configure correctly?  Btw,
> udev system do not support autoloading of modules, so you
> have to add it to /etc/modules.autoload.d/kernel-2.6, but
> then the device nodes should be created automatically ...

OK, there is a problem with the nvidia-kernel ebuild -- it doesn't work on
KOUTPUT kernels.  I already opened a bug about it:
http://bugs.gentoo.org/show_bug.cgi?id=58294 but a minute ago I also submitted
the fix.

You say you were responsible for the fixes, so go get the bug while it's fresh. ;)

-- 
\    Georgi Georgiev   \  Flon's Law: There is not now, and never      \
 /    chutz@gg3.net     / will be, a language in which it is the        /
\   +81(90)6266-1163   \  least bit difficult to write bad programs.   \

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

Re: [gentoo-dev] Kernel sources thread

[Norberto Bensa]

Travis Tilley wrote:
> On Wednesday 21 July 2004 01:28 am, Greg KH wrote:
> > Oh, and that reminds me to go make up a "delete devfs" kernel patch to
> > send off to lkml, just to force the issue :)
>
> heh.

I wasn't joke :D

Greg sent a patch to LKML to do just that. Bye bye devfs...

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Greg KH]

On Wed, Jul 21, 2004 at 03:24:56AM -0400, Travis Tilley wrote:
> On Wednesday 21 July 2004 01:28 am, Greg KH wrote:
> > On Sun, Jul 18, 2004 at 06:53:29PM -0400, Travis Tilley wrote:
> > > please dont force udev on me... i refuse to use that crap. :|
> >
> > I welcome constructive criticism all the time.  This was not it.
> >
> > If you have _any_ issues with udev, please let the developers and the
> > linux-hotplug-devel mailing list know about it.  Otherwise it will not
> > get fixed, and you will never be happy.
> 
> just dont -force- udev on me and i'll be happy.

I'm not, you can use either a static device tree or udev, it's your
choice :)

> > Oh, and that reminds me to go make up a "delete devfs" kernel patch to
> > send off to lkml, just to force the issue :)
> 
> heh.

And you thought I was kidding:
	http://thread.gmane.org/gmane.linux.kernel/219278

We are changing the way kernel development is viewed...

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Greg KH]

Sorry for the lag, was at the Linux kernel summit and now OLS, so email
access is spotty...

On Sat, Jul 17, 2004 at 01:32:18AM +0100, Ciaran McCreesh wrote:
> On Fri, 16 Jul 2004 17:06:20 -0700 Greg KH <gregkh@gentoo.org> wrote:
> | > The 2.6.x patchset is a *lot* cleaner. I'm not the only dev who
> | > still has strong objections to at least one of the patches that's
> | > included in there, however.
> | 
> | Which one, supermount?
> 
> No, supermount is just pointless, since we've got udev and dev.d

Is this really true?  If so, great, I'll drop it right now.  I really
don't know what supermount is used for these days...

> The objectionable patch is bootsplash. Chances are everyone's
> already heard wesolows' rant about this, and I agree with everything he
> says, so I won't repeat it here.

Um, where would this rant be?  Yes, the older code was not nice.  But
look at it now.  It's self contained, and is easily disabled with no
side affects (and if there are any, please file bugs and we will fix
them.)

And the next-gen bootsplash code rocks.  It's done properly, and I'm
going to be working on getting it into the mainline kernel tree.  Spock
has done a kick-ass job on this.

> (Incidentally, until recently bootsplash would change the fb code even
> when it was disabled, and it screwed thing up enough that I had to
> revert the patch.)

That is fixed, so this issue is now mute.

> | As of right now, there are only 4 "features" added to the g-d-s kernel
> | package, all for very good reason.
> 
> Is one of those reasons "looking pretty at the expense of hiding the
> messages which show why your keyboard isn't working"? :)

For some reason people like pretty things :)

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Wade Nelson]

looking for some clarification here....

is development-sources a pure kernel.org 2.6.x kernel or not?

shouldn't vanilla-sources always reflect the current kernel.org stable 
kernel version, with a seperate branch for (deprecated is a bad term 
here) 2.4.x kernels?

If the above statement were true (vanilla == kernel.org) we wouldn't 
need development-sources at all, correct? if vanilla were to adopt the 
"latest kernel.org non-rc" status, development-sources could be removed 
and a 2.4 branch could be added, resulting in 0 extra -sources.

IMHO, g-s should be the latest kernel.org sources that have been "proven 
stable" with patches X,Y,Z, while g-d-s would be the testing ground for 
g-s... could this also be accomplished keywording g-s accordingly, 
negating the necessity of g-d-s if this were the case?

personally, I think ck and mm need not be in portage... if someone wants 
to take the risk of running such sources, said person should be 
perfectly capable of applying the patches.

sorry if this is a little OT, but it seems the state of *-sources is in 
a bit of disarray from my point of view... also take note that I'm only 
considering x86 here, since I have little (read virtually zero) 
experience with kernels outside the scope of x86.....

and I mean no disrespect to the gentoo kernel devs :)

--Wade

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Kernel sources thread

[Greg KH]

On Sat, Jul 17, 2004 at 12:33:04AM -0500, Wade Nelson wrote:
> looking for some clarification here....

<snip>

Yes, the current situation with all of the different kernels is quite
confusing.  The kernel developers are all getting together to hash out
the direction and purpose of all of these different packages next week,
because of user confusion like this thread, and other recent issues that
have come about.

After that point, everyone will be notified as to what the kernel
situation is, please bear with us for a little while longer.

Oh, and as for the very original poster that was mentioned on the thread
from the XFS list, I have spoken to him numerous times, as I frequent
the same irc channels as he does, and his hatred/ignorance of gentoo,
and it's users and developers is quite great.  I encourage everyone to
treat his comments with huge grains of salt.  Personally, I just ignore
him now, and don't rise to his trolls.

> and I mean no disrespect to the gentoo kernel devs :)

No disrespect taken. :)

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list