some changes for (slightly) faster boot

[Bill Nottingham]

In tomorrow's rawhide should be kudzu-1.105-1 and initscripts-8.02-1.
These implement various changes for speeding up bootup some:

- removal of initlog and minilogd

Basically, the things that were logged before syslog started were
generally uninteresting, and it added a surprising amount of delay
to the bootup. There should/will be a better mechanism
for recording whether services start succesfully added at some point
later.

- hack to allow kudzu to read the devices from a socket from kmodule

This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

The combination of these should speed up the boot a somewhat
noticeable amount of time compared to stock FC3. Currently, there
are the following issues:

- text boot is now more noisy

initlog did hide some spew from various services; this needs cleaned up.

- things that try to call initlog will simply fail

openssh and Canna should be fixed. Other things will need fixed.
I suppose a initlog wrapper that accepts the same syntax and just
'execs' may be useful, but it's probably best to do a clean break
and see what happens.

Bill

[Jeff Spaleta]

Post by Bill Nottingham
- hack to allow kudzu to read the devices from a socket from kmodule
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

-jef

[Bill Nottingham]

Post by Jeff Spaleta

Post by Bill Nottingham
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Bill

[Paul]

Hi,

Post by Bill Nottingham

Post by Jeff Spaleta
Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Excellent. Now to get my system to actually allow me to install rpms
without constantly giving me preun and postun errors!

rpm --vv isn't being very helpful...

TTFN

Paul
--
"He's not the Messiah, he's a very naughty boy!"
- Life of Brian, Monty Python
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050103/bc515db7/attachment.bin

[Paul Nasrat]

Post by Paul
Hi,

Post by Bill Nottingham

Post by Jeff Spaleta
Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Excellent. Now to get my system to actually allow me to install rpms
without constantly giving me preun and postun errors!
rpm --vv isn't being very helpful...

Have you addressed this in bugzilla, rpm HEAD on rawhide is fine here?

Paul

[Paul]

Hi,

Post by Paul Nasrat

Post by Paul
Excellent. Now to get my system to actually allow me to install rpms
without constantly giving me preun and postun errors!
rpm --vv isn't being very helpful...

Have you addressed this in bugzilla, rpm HEAD on rawhide is fine here?

As I can't reproduce it on any other rawhide box, I'm putting it down to
this box until I can prove otherwise.

TTFN

Paul
--
"He's not the Messiah, he's a very naughty boy!"
- Life of Brian, Monty Python
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050103/1273590e/attachment.bin

[Paul]

Hi,

Post by Paul Nasrat

Post by Paul
Excellent. Now to get my system to actually allow me to install rpms
without constantly giving me preun and postun errors!
rpm --vv isn't being very helpful...

Have you addressed this in bugzilla, rpm HEAD on rawhide is fine here?

As I can't reproduce it on any other rawhide box, I'm putting it down to
this box until I can prove otherwise.

TTFN

Paul
--
"He's not the Messiah, he's a very naughty boy!"
- Life of Brian, Monty Python
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050103/1273590e/attachment-0002.bin

[Michael Schwendt]

Post by Paul
Hi,

Post by Bill Nottingham

Post by Jeff Spaleta
Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Excellent. Now to get my system to actually allow me to install rpms
without constantly giving me preun and postun errors!
rpm --vv isn't being very helpful...

"rpm --query --scripts" on the package might be more helpful.
Many scriptlets are executed in /bin/sh, so first make sure your
/bin/sh works completely, then look what script contents fail.

[Paul]

Hi,

Post by Michael Schwendt
"rpm --query --scripts" on the package might be more helpful.

Okay...

preinstall scriptlet (using /bin/sh):
/sbin/modprobe loop 2> /dev/null > /dev/null || :
exit 0
postinstall scriptlet (using /bin/sh):
[ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --package kernel --
mkinitrd --depmod --install 2.6.10-1.1056_FC4
if [ -x /usr/sbin/hardlink ] ; then
pushd /lib/modules/2.6.10-1.1056_FC4/build > /dev/null ; {
cd /lib/modules/2.6.10-1.1056_FC4/build
find . -type f | while read f; do hardlink -c /lib/modules/*/build/$f
$f ; done
}
popd > /dev/null
fi
preuninstall scriptlet (using /bin/sh):
/sbin/modprobe loop 2> /dev/null > /dev/null || :
[ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --rminitrd --
rmmoddep --remove 2.6.10-1.1056_FC4

Post by Michael Schwendt
Many scriptlets are executed in /bin/sh, so first make sure your
/bin/sh works completely, then look what script contents fail.

I can start /bin/sh from the command line. Is there any way to test
everything is functioning under it? Installing a kernel always fails on
pre.

I can run the preinstall script happily within /bin/sh

TTFN

Paul
--
"He's not the Messiah, he's a very naughty boy!"
- Life of Brian, Monty Python
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050103/96a4079a/attachment.bin

[Michael Schwendt]

Post by Paul
Hi,

Post by Michael Schwendt
"rpm --query --scripts" on the package might be more helpful.

Okay...
exit 0

As one observation, the scriptlet itself always returns exit code 0
(true), so that raises the question why rpm sees exit code 255?
What does an strace say at that part?

D: install: kernel-2.6.10-1.1056_FC4 has 8380 files, test = 0
D: install: %pre(kernel-2.6.10-1.1056_FC4.i686) asynchronous scriptlet start
D: install: %pre(kernel-2.6.10-1.1056_FC4.i686) execv(/bin/sh) pid 5058
D: install: waitpid(5058) rc 5058 status ff00 secs 0.002
error: %pre(kernel-2.6.10-1.1056_FC4.i686) scriptlet failed, exit status 255
error: install: %pre scriptlet failed (2), skipping kernel-2.6.10-1.1056_FC4

Post by Paul

Post by Michael Schwendt
Many scriptlets are executed in /bin/sh, so first make sure your
/bin/sh works completely, then look what script contents fail.

I can start /bin/sh from the command line. Is there any way to test
everything is functioning under it? Installing a kernel always fails on
pre.
I can run the preinstall script happily within /bin/sh

[Michael Schwendt]

Post by Paul
Hi,

Post by Michael Schwendt
"rpm --query --scripts" on the package might be more helpful.

Okay...
exit 0

As one observation, the scriptlet itself always returns exit code 0
(true), so that raises the question why rpm sees exit code 255?
What does an strace say at that part?

D: install: kernel-2.6.10-1.1056_FC4 has 8380 files, test = 0
D: install: %pre(kernel-2.6.10-1.1056_FC4.i686) asynchronous scriptlet start
D: install: %pre(kernel-2.6.10-1.1056_FC4.i686) execv(/bin/sh) pid 5058
D: install: waitpid(5058) rc 5058 status ff00 secs 0.002
error: %pre(kernel-2.6.10-1.1056_FC4.i686) scriptlet failed, exit status 255
error: install: %pre scriptlet failed (2), skipping kernel-2.6.10-1.1056_FC4

Post by Paul

Post by Michael Schwendt
Many scriptlets are executed in /bin/sh, so first make sure your
/bin/sh works completely, then look what script contents fail.

I can start /bin/sh from the command line. Is there any way to test
everything is functioning under it? Installing a kernel always fails on
pre.
I can run the preinstall script happily within /bin/sh

[Paul]

Hi,

Post by Michael Schwendt
"rpm --query --scripts" on the package might be more helpful.

Okay...

preinstall scriptlet (using /bin/sh):
/sbin/modprobe loop 2> /dev/null > /dev/null || :
exit 0
postinstall scriptlet (using /bin/sh):
[ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --package kernel --
mkinitrd --depmod --install 2.6.10-1.1056_FC4
if [ -x /usr/sbin/hardlink ] ; then
pushd /lib/modules/2.6.10-1.1056_FC4/build > /dev/null ; {
cd /lib/modules/2.6.10-1.1056_FC4/build
find . -type f | while read f; do hardlink -c /lib/modules/*/build/$f
$f ; done
}
popd > /dev/null
fi
preuninstall scriptlet (using /bin/sh):
/sbin/modprobe loop 2> /dev/null > /dev/null || :
[ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --rminitrd --
rmmoddep --remove 2.6.10-1.1056_FC4

Post by Michael Schwendt
Many scriptlets are executed in /bin/sh, so first make sure your
/bin/sh works completely, then look what script contents fail.

I can start /bin/sh from the command line. Is there any way to test
everything is functioning under it? Installing a kernel always fails on
pre.

I can run the preinstall script happily within /bin/sh

TTFN

Paul
--
"He's not the Messiah, he's a very naughty boy!"
- Life of Brian, Monty Python
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050103/96a4079a/attachment-0002.bin

[Paul Nasrat]

Post by Paul
Hi,

Post by Bill Nottingham

Post by Jeff Spaleta
Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Excellent. Now to get my system to actually allow me to install rpms
without constantly giving me preun and postun errors!
rpm --vv isn't being very helpful...

Have you addressed this in bugzilla, rpm HEAD on rawhide is fine here?

Paul

[Michael Schwendt]

Post by Paul
Hi,

Post by Bill Nottingham

Post by Jeff Spaleta
Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Excellent. Now to get my system to actually allow me to install rpms
without constantly giving me preun and postun errors!
rpm --vv isn't being very helpful...

"rpm --query --scripts" on the package might be more helpful.
Many scriptlets are executed in /bin/sh, so first make sure your
/bin/sh works completely, then look what script contents fail.

[Dax Kelson]

Post by Bill Nottingham

Post by Jeff Spaleta

Post by Bill Nottingham
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Not good for many situations. For example:

Currently my wireless NIC (Intel 2200BG) uses a out-of-kernel driver.

Whenever Fedora releases an updated kernel and I reboot kudzu wants to
remove my wireless NIC as I haven't recompiled my driver yet.

I DO NOT want kudzu removing the configuration (very very long WEP keys,
and other hand entered wireless settings).

The behavior, as described, is unacceptable IMHO.

Dax Kelson
Guru Labs

[Havoc Pennington]

IMO the root problem if this breaks is mixing of autoprobe data with
user configuration. We need to fix it by unmixing those things, not by
breaking autoprobe or losing people's config files.

Here is the basic flow you want:

autoprobe and write out automated data about devices and drivers ->
apply user-provided overrides and edits to autoprobed information ->
autodetermine reasonable behavior in light of device details ->
apply user-provided overrides and edits to default behavior ->
invoke behavior

So a concrete example:

autoprobe ethernet card model Foo with details blah blah ->
user wants to use alternate driver or work around hardware bug,
said override data loaded ->
autodetermine that if a link is present device should be brought up
with dhcp ->
user has specified that device should only be brought up manually ->
device is now configured to come up manually with alternate driver

Or whatever, you see the point.

It's easy enough to see that we can have whitelists/blacklists inserted
into the flow, so e.g. OS vendors or OEMs can provide overrides as well.

The same basic idea is where we want to be going with X server
configuration: the config file should contain only a delta from the
default behavior.

Or for that matter, something like "profile.d" is the same basic idea.
Don't mix the automatically-created data, the vendor-provided data, and
the site local data.

I think it's fine to switch the default to autoprobe always in rawhide,
it will encourage someone to fix the root problem ;-) but we probably
can't ship with autoprobe until we unmix data from distinct sources.

Havoc

[Havoc Pennington]

IMO the root problem if this breaks is mixing of autoprobe data with
user configuration. We need to fix it by unmixing those things, not by
breaking autoprobe or losing people's config files.

Here is the basic flow you want:

autoprobe and write out automated data about devices and drivers ->
apply user-provided overrides and edits to autoprobed information ->
autodetermine reasonable behavior in light of device details ->
apply user-provided overrides and edits to default behavior ->
invoke behavior

So a concrete example:

autoprobe ethernet card model Foo with details blah blah ->
user wants to use alternate driver or work around hardware bug,
said override data loaded ->
autodetermine that if a link is present device should be brought up
with dhcp ->
user has specified that device should only be brought up manually ->
device is now configured to come up manually with alternate driver

Or whatever, you see the point.

It's easy enough to see that we can have whitelists/blacklists inserted
into the flow, so e.g. OS vendors or OEMs can provide overrides as well.

The same basic idea is where we want to be going with X server
configuration: the config file should contain only a delta from the
default behavior.

Or for that matter, something like "profile.d" is the same basic idea.
Don't mix the automatically-created data, the vendor-provided data, and
the site local data.

I think it's fine to switch the default to autoprobe always in rawhide,
it will encourage someone to fix the root problem ;-) but we probably
can't ship with autoprobe until we unmix data from distinct sources.

Havoc

[Jeff Spaleta]

Post by Bill Nottingham
Yes. Hence, a large shaking out period.

fun! I hope that shaking out period includes an effort to make kudzu
aware of local changes so that local configurations can be restored
instead of kudzu defaults when the hardware is found again. Auto
removal isn't a bad thing... as long as there is a way to save and
restore state information so kudzu's defaults are not relied on over
and over again.

As people have already pointed again in this thread... there is a
communication gap in what kudzu wants as a configuration for some
devices.. and what local admin/user wants. Is the hal/network-manager
software stack suppose to provide the missing piece of the puzzle so
that kudzu doesn't have to deal with site specific configs?

-jef"as much fun as a dental visit"spaleta

[Bill Nottingham]

Post by Jeff Spaleta
As people have already pointed again in this thread... there is a
communication gap in what kudzu wants as a configuration for some
devices.. and what local admin/user wants. Is the hal/network-manager
software stack suppose to provide the missing piece of the puzzle so
that kudzu doesn't have to deal with site specific configs?

It's part of it.

Realistically, the only sort of device that has a lot of site-local
configuration is a network card; for most other things you don't care.

Hence, where we're probably going to end up is that kudzu will, at
most, handle things like modprobe.conf aliases for networking;
actual config will be handled by something like NetworkManager,
and system-config-network.

Bill

[Alexandre Oliva]

Post by Bill Nottingham
Realistically, the only sort of device that has a lot of site-local
configuration is a network card; for most other things you don't care.

Hmm, let's see...

- Printer: probably want to keep customizations such as default page
size, paper tray, etc

- Mouse: emulate the middle button or not.

- Keyboard: what's the key layout

- Display: what depth, resolution to use

- Hard disks: where to mount


So what other kinds of devices whose local configurations didn't
matter did you have in mind anyway?

[Bill Nottingham]

Post by Alexandre Oliva

Post by Bill Nottingham
Realistically, the only sort of device that has a lot of site-local
configuration is a network card; for most other things you don't care.

Hmm, let's see...
- Printer: probably want to keep customizations such as default page
size, paper tray, etc
- Mouse: emulate the middle button or not.
- Keyboard: what's the key layout
- Display: what depth, resolution to use
- Hard disks: where to mount
So what other kinds of devices whose local configurations didn't
matter did you have in mind anyway?

Let me rephrase...

'local configuration that the tool currently touches'.

Bill

[Nicolas Mailhot]

Post by Alexandre Oliva

Post by Bill Nottingham
Realistically, the only sort of device that has a lot of site-local
configuration is a network card; for most other things you don't care.

Hmm, let's see...
- Printer: probably want to keep customizations such as default page
size, paper tray, etc

resolution...

Post by Alexandre Oliva
- Mouse: emulate the middle button or not.

button order, acceleration...

Post by Alexandre Oliva
- Keyboard: what's the key layout

special keys...

Post by Alexandre Oliva
- Display: what depth, resolution to use

xinerama, tv-out...

Post by Alexandre Oliva
- Hard disks: where to mount

(or not)

Post by Alexandre Oliva
So what other kinds of devices whose local configurations didn't
matter did you have in mind anyway?

- Sound: output to use (analog or spdif)
- Flash reader: where to mount, treat as ro or rw...

(and that's about all the devices I own. I'm pretty sure if I bought
another one I *would* find some user customization to save since I'm a
compulsive tweaker)

Regards,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050104/2d82f97c/attachment.bin

[Colin Walters]

Post by Alexandre Oliva

Post by Bill Nottingham
Realistically, the only sort of device that has a lot of site-local
configuration is a network card; for most other things you don't care.

Hmm, let's see...
- Printer: probably want to keep customizations such as default page
size, paper tray, etc
- Mouse: emulate the middle button or not.
- Keyboard: what's the key layout
- Display: what depth, resolution to use

These all look like per-user preferences to me. So they should be
stored in GConf.

Post by Alexandre Oliva
- Hard disks: where to mount

How do you configure this now?

[seth vidal]

Post by Colin Walters

Post by Alexandre Oliva
- Display: what depth, resolution to use

These all look like per-user preferences to me. So they should be
stored in GConf.

not for the default X configuration.

-sv

[Jeremy Katz]

Post by seth vidal

Post by Colin Walters

Post by Alexandre Oliva
- Display: what depth, resolution to use

These all look like per-user preferences to me. So they should be
stored in GConf.

not for the default X configuration.

But if switching this stuff is easy (yes, I know you can't switch depths
right now so this can't 100% apply), then why not have the default X
configuration just be something sane given the monitor. ie, if it's a
flat panel, you want the native resolution of the panel, otherwise you
want just a basic resolution. It's not like logging in requires a lot
of screen real estate.

Jeremy

[seth vidal]

Post by Jeremy Katz
But if switching this stuff is easy (yes, I know you can't switch depths
right now so this can't 100% apply), then why not have the default X
configuration just be something sane given the monitor. ie, if it's a
flat panel, you want the native resolution of the panel, otherwise you
want just a basic resolution. It's not like logging in requires a lot
of screen real estate.

Only if you're not visually impaired, or don't want to change from the
default session.

native resolution on most lcds is way too small for folks with various
eyesight problems.

-sv

[Alan Cox]

Post by Jeremy Katz
right now so this can't 100% apply), then why not have the default X
configuration just be something sane given the monitor. ie, if it's a
flat panel, you want the native resolution of the panel, otherwise you
want just a basic resolution. It's not like logging in requires a lot
of screen real estate.

The only "safe" resolution without DDC is 640x480 at 60Hz 31.5Khz (ie VGA)
unless it is a panel. gdm doesn't work at 640x480 in our setup (bugzilla'd
about RH8, never fixed). (TV out is an exception but we don't really handle
TV out sanely yet anyway so its not a revert)

[Jeremy Katz]

Post by Alan Cox

Post by Jeremy Katz
right now so this can't 100% apply), then why not have the default X
configuration just be something sane given the monitor. ie, if it's a
flat panel, you want the native resolution of the panel, otherwise you
want just a basic resolution. It's not like logging in requires a lot
of screen real estate.

The only "safe" resolution without DDC is 640x480 at 60Hz 31.5Khz (ie VGA)
unless it is a panel. gdm doesn't work at 640x480 in our setup (bugzilla'd
about RH8, never fixed). (TV out is an exception but we don't really handle
TV out sanely yet anyway so its not a revert)

One nice thing about having X set the defaults is that (in general) the
X drivers know the card-specific probing routines for what monitor is
attached and so we don't have to rely on the admittedly crappy
information you can get with real mode monitor probing. And then a lot
more becomes "safe"

Jeremy

[Jonathan Andrews]

Post by Alan Cox

Post by Jeremy Katz
right now so this can't 100% apply), then why not have the default X
configuration just be something sane given the monitor. ie, if it's a
flat panel, you want the native resolution of the panel, otherwise you
want just a basic resolution. It's not like logging in requires a lot
of screen real estate.

The only "safe" resolution without DDC is 640x480 at 60Hz 31.5Khz (ie VGA)
unless it is a panel. gdm doesn't work at 640x480 in our setup (bugzilla'd
about RH8, never fixed). (TV out is an exception but we don't really handle
TV out sanely yet anyway so its not a revert)

^^ I would just like to stick my foot in and say that redhat break
TV-out installs on most hardware with "setsysfont". This seems to render
most ATI based cards black in way that even starting X doesnt recover
from.

Anyone know if this is fixed in core3 ?

Thanks,
Jon

[Alan Cox]

Post by Jonathan Andrews
^^ I would just like to stick my foot in and say that redhat break
TV-out installs on most hardware with "setsysfont". This seems to render
most ATI based cards black in way that even starting X doesnt recover
from.

New one on me - is this in bugzilla ?

[Jonathan Andrews]

Post by Alan Cox

Post by Jonathan Andrews
^^ I would just like to stick my foot in and say that redhat break
TV-out installs on most hardware with "setsysfont". This seems to render
most ATI based cards black in way that even starting X doesnt recover
from.

New one on me - is this in bugzilla ?

I cant find in fedora bugzilla - but I also cant find much reference to
setsysfont. I mentioned it on a developers list about a year ago and was
told no simple work around was possible, but ive long since
lost/forgotten the details.

"setsysfont" is part of what component ?


Its easy to reproduce, stick any TV out ATI card in a machine, connect
the TV output only (the ATI card defaults to TV only in this case) then
boot the CD .... The kernel comes up all nice then goes black early on
during startup. I had problems with the epia machines and TV out in the
same way, its easy to fix on an installed copy by commenting setsysfont
out - but less easy to work around with the installers ! Annoyingly even
the text install runs setsysfont :-(

Its a shame, because other than this issue the fb mode works fine with
tv out, you could say I watch X on the telly ;-)

Jon

[Alan Cox]

Post by Jonathan Andrews
"setsysfont" is part of what component ?

rpm -qf /sbin/setsysfont

(initscripts)

[Jonathan Andrews]

Post by Alan Cox

Post by Jonathan Andrews
"setsysfont" is part of what component ?

rpm -qf /sbin/setsysfont
(initscripts)

Ta!

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144206

[Nicolas Mailhot]

Post by Colin Walters

Post by Alexandre Oliva

Post by Bill Nottingham
Realistically, the only sort of device that has a lot of site-local
configuration is a network card; for most other things you don't care.

Hmm, let's see...
- Printer: probably want to keep customizations such as default page
size, paper tray, etc
- Mouse: emulate the middle button or not.
- Keyboard: what's the key layout
- Display: what depth, resolution to use

These all look like per-user preferences to me. So they should be
stored in GConf.

Not all of them :

- some printers accept extensions (memory, supplementary trays,
duplexing unit...) that are not detectable and must be specified
manually by the admin somewhere

- mouse : physical setup (wheel...) will almost always be shared among
users (even if modern devices make this less a problem than before)

- keyboard : again different users may use different layouts but some
characteristics like key number are shared

Sure you can have every user redefine every single parameter - but even
if users with different tastes do happen very frequently, the vast
majority of cases will be users sharing the same customisations (because
of the site/corporate policy, or there is only one computer-addict in
the family, etc). This is BTW one of GConf biggest weaknesses right now
- it's easy to change things on a per-user basis, but much less so on a
per-system (or per-group) one, unless you want to dig into GConf
internals and fight your distribution idea of what the defaults should
be.

Post by Colin Walters

Post by Alexandre Oliva
- Hard disks: where to mount

How do you configure this now?

Crazy udev manual rules;)

Regards,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050104/e388ac78/attachment.bin

[Bryan Clark]

Your logic across all of this weighs on the fact that it is difficult
for admins to setup defaults or for users to share defaults among
machines. Say we were to change that problem, then these would all be
per-user preferences again, yes? :-)

Cheers,
~ Bryan

Post by Nicolas Mailhot

Post by Colin Walters
These all look like per-user preferences to me. So they should be
stored in GConf.

- some printers accept extensions (memory, supplementary trays,
duplexing unit...) that are not detectable and must be specified
manually by the admin somewhere
- mouse : physical setup (wheel...) will almost always be shared among
users (even if modern devices make this less a problem than before)
- keyboard : again different users may use different layouts but some
characteristics like key number are shared
Sure you can have every user redefine every single parameter - but even
if users with different tastes do happen very frequently, the vast
majority of cases will be users sharing the same customisations (because
of the site/corporate policy, or there is only one computer-addict in
the family, etc). This is BTW one of GConf biggest weaknesses right now
- it's easy to change things on a per-user basis, but much less so on a
per-system (or per-group) one, unless you want to dig into GConf
internals and fight your distribution idea of what the defaults should
be.

[Alan Cox]

Post by Bryan Clark
Your logic across all of this weighs on the fact that it is difficult
for admins to setup defaults or for users to share defaults among
machines. Say we were to change that problem, then these would all be
per-user preferences again, yes? :-)

per-user per-system in some cases. I use the same /home from US and UK
keyboards and 3 different display sizes. I'm sure that isn't too unusual

[Havoc Pennington]

Post by Alan Cox

Post by Bryan Clark
Your logic across all of this weighs on the fact that it is difficult
for admins to setup defaults or for users to share defaults among
machines. Say we were to change that problem, then these would all be
per-user preferences again, yes? :-)

per-user per-system in some cases. I use the same /home from US and UK
keyboards and 3 different display sizes. I'm sure that isn't too unusual

You can actually convince gconf to deal with that (if you want to go
command line) by adding a ~/.gconf.<systemid>, setting systemid in some
env variable, adding ~/.gconf.path to include ~/.gconf.$(ENV_<whatever>)

A bit hacky but it does the job. I don't really have a clue how we'd
expose this in the GUI, anyhow, other than just automatically saving
things keyed by screen size or other hardware attributes.

Havoc

[Alexandre Oliva]

Post by Havoc Pennington
A bit hacky but it does the job. I don't really have a clue how we'd
expose this in the GUI, anyhow

Let the user create desktop profiles, and do per-profile
configurations? Then let the user choose which profile to use for a
session, and remember the last profile used on a host and use that as
default? For bonus points, introduce profile inheritance, and let the
user choose in which point of the profile inheritance to store some
specific setting.

[Havoc Pennington]

Post by Alexandre Oliva

Post by Havoc Pennington
A bit hacky but it does the job. I don't really have a clue how we'd
expose this in the GUI, anyhow

Let the user create desktop profiles, and do per-profile
configurations? Then let the user choose which profile to use for a
session, and remember the last profile used on a host and use that as
default? For bonus points, introduce profile inheritance, and let the
user choose in which point of the profile inheritance to store some
specific setting.

We started doing this years ago, but it basically sucked because most of
the time you want a profile to cover only a couple of settings, not all
of them. Plus profiles as a concept are pretty complex (especially with
inheritance).

Another way to put it, once you have inheritance and limit profiles to
particular keys, your tool for manipulating profiles is going to be on
the level of gconf-editor, not on the level of control center.

So to me we're better off just saying "the desktop should dynamically
adapt to various resolutions" for example (we really need to do that
anyhow, for the default configuration).

Havoc

[Alan Cox]

Post by Havoc Pennington
So to me we're better off just saying "the desktop should dynamically
adapt to various resolutions" for example (we really need to do that
anyhow, for the default configuration).

SGI had per desktop profiles on IRIX as an option. In most respects I'd second
Havoc that if the desktop would just mind its own business the world will be
happy. That will need tools like metacity to grow up and start behaving
better. It would also need smarter awareness of resolution and dpi - eg if
I move from 1600x1200 analog to 1024x768 on the laptop tft the right move
for gnome-terminal is smaller fonts not 40x16 windows.

The advantages of the SGI setup moving from very big to small displays was
you got a sane desktop. The disadvantage was that you had to keep them in sync
by hand and it got to be a real PITA.

[Nicolas Mailhot]

Post by Alan Cox

Post by Havoc Pennington
So to me we're better off just saying "the desktop should dynamically
adapt to various resolutions" for example (we really need to do that
anyhow, for the default configuration).

SGI had per desktop profiles on IRIX as an option. In most respects I'd second
Havoc that if the desktop would just mind its own business the world will be
happy. That will need tools like metacity to grow up and start behaving
better. It would also need smarter awareness of resolution and dpi - eg if
I move from 1600x1200 analog to 1024x768 on the laptop tft the right move
for gnome-terminal is smaller fonts not 40x16 windows.

ie use the real dpi setting as provided by xorg instead of forcing 96
dpi everywhere to match windows (and add a user-side relative zoom
factor to take into account people with bad eyes)

With modern screens you get nicer display with the highest dpi available
instead of limiting yourself to 96 anyway.

Regards,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050106/9b6c4dfd/attachment.bin

[Shahms King]

Post by Nicolas Mailhot

Post by Alan Cox

Post by Havoc Pennington
So to me we're better off just saying "the desktop should dynamically
adapt to various resolutions" for example (we really need to do that
anyhow, for the default configuration).

SGI had per desktop profiles on IRIX as an option. In most respects I'd second
Havoc that if the desktop would just mind its own business the world will be
happy. That will need tools like metacity to grow up and start behaving
better. It would also need smarter awareness of resolution and dpi - eg if
I move from 1600x1200 analog to 1024x768 on the laptop tft the right move
for gnome-terminal is smaller fonts not 40x16 windows.

ie use the real dpi setting as provided by xorg instead of forcing 96
dpi everywhere to match windows (and add a user-side relative zoom
factor to take into account people with bad eyes)
With modern screens you get nicer display with the highest dpi available
instead of limiting yourself to 96 anyway.
Regards,

Sometimes the DPI returned from the DDC probe isn't accurate,
however . . .

As a side note and "me too!" though, my SGI 1600SW flat panel *does*
report DPI correctly at 108 (or 106, I can't remember) and unless I
manually change this, the sub-pixel anti-aliasing produces very visible
green and red outlines.

[Nicolas Mailhot]

Post by Shahms King

Post by Nicolas Mailhot

Post by Alan Cox

Post by Havoc Pennington
So to me we're better off just saying "the desktop should dynamically
adapt to various resolutions" for example (we really need to do that
anyhow, for the default configuration).

SGI had per desktop profiles on IRIX as an option. In most respects I'd second
Havoc that if the desktop would just mind its own business the world will be
happy. That will need tools like metacity to grow up and start behaving
better. It would also need smarter awareness of resolution and dpi - eg if
I move from 1600x1200 analog to 1024x768 on the laptop tft the right move
for gnome-terminal is smaller fonts not 40x16 windows.

ie use the real dpi setting as provided by xorg instead of forcing 96
dpi everywhere to match windows (and add a user-side relative zoom
factor to take into account people with bad eyes)
With modern screens you get nicer display with the highest dpi available
instead of limiting yourself to 96 anyway.
Regards,

Sometimes the DPI returned from the DDC probe isn't accurate,
however . . .

But you can always force a screen size in xorg.conf...
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050106/0d12eb8c/attachment.bin

[Havoc Pennington]

Post by Nicolas Mailhot
Sure you can have every user redefine every single parameter - but even
if users with different tastes do happen very frequently, the vast
majority of cases will be users sharing the same customisations (because
of the site/corporate policy, or there is only one computer-addict in
the family, etc). This is BTW one of GConf biggest weaknesses right now
- it's easy to change things on a per-user basis, but much less so on a
per-system (or per-group) one, unless you want to dig into GConf
internals and fight your distribution idea of what the defaults should
be.

You shouldn't have to fight the distribution if you do it properly
(granted "properly" isn't necessarily obvious); the distribution
defaults are in the schemas and the site-local defaults should be set as
the values themselves.

There are plans to make it simpler:
http://www.gnome.org/projects/gconf/plans.html
but I believe it works fine now once you figure it out.

To set a default do something like:
gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults --set /apps/metacity/general/reduced_resources true

all users should then get reduced_resources=true by default and AFAIK
Red Hat packages will never overwrite this.

If you run gconf-editor as root and choose "New Defaults Window" and
change stuff there, in principle that's the same as the above command
line.

Making this a bit worse, gnome-panel specifically (which I realize is
the app most people want to set up defaults for) is harder than other
apps.
http://mail.gnome.org/archives/gconf-list/2003-December/msg00007.html
http://mail.gnome.org/archives/gconf-list/2003-December/msg00012.html

Havoc

[Alan Cox]

Post by Colin Walters

Post by Alexandre Oliva
- Keyboard: what's the key layout

These all look like per-user preferences to me. So they should be
stored in GConf.

So you don't believe people should be able to log in. Let me set your box
to default to gdm with an azerty keyboard and left handed mouse and then see
if you still think its a per user preference.

Oh and perhaps with the video at a resolution your monitor can't handle.

Lots of these are both system preferences and user ones with the user able
to configure some properties or properties within a constraint set by the
system (eg video mode).

Alan

[Colin Walters]

Post by Alan Cox

Post by Colin Walters

Post by Alexandre Oliva
- Keyboard: what's the key layout

These all look like per-user preferences to me. So they should be
stored in GConf.

So you don't believe people should be able to log in. Let me set your box
to default to gdm with an azerty keyboard and left handed mouse and then see
if you still think its a per user preference.

I don't understand this; clearly if I have to use an azerty keyboard
layout I'm screwed whether or not you set it on the system or just for
my user. How is this different from you setting azerty as the default
in the Xorg conf file?

Post by Alan Cox
Oh and perhaps with the video at a resolution your monitor can't handle.

At least with modern monitors it's my understanding the X server knows
what the monitor supports (DDC or something?). So the system could
prevent a user from changing their preference to something invalid.
Thus it becomes a preference rather than a setting.

Post by Alan Cox
Lots of these are both system preferences

GConf does have an idea of a default preference.

Post by Alan Cox
and user ones with the user able
to configure some properties or properties within a constraint set by the
system (eg video mode).

Sure, I agree the system should only accept valid input from the user.

[Alan Cox]

Post by Colin Walters
I don't understand this; clearly if I have to use an azerty keyboard
layout I'm screwed whether or not you set it on the system or just for
my user. How is this different from you setting azerty as the default
in the Xorg conf file?

It proves that keyboard is a system setting.

Post by Colin Walters

Post by Alan Cox
Oh and perhaps with the video at a resolution your monitor can't handle.

At least with modern monitors it's my understanding the X server knows
what the monitor supports (DDC or something?). So the system could
prevent a user from changing their preference to something invalid.
Thus it becomes a preference rather than a setting.

It remains a system setting (or the range does), and that needs to be kept
by Kudzu attached to the hardware even when the hardware vanishes for a while.

[Havoc Pennington]

Post by Alan Cox
Lots of these are both system preferences and user ones with the user able
to configure some properties or properties within a constraint set by the
system (eg video mode).

Keep in mind that "user preference" implies a search path
(the default search path is:
- systemwide mandatory
- per-user
- systemwide defaults
- factory defaults)

Normally we want the "driver layer" (in the sense of
http://mail.gnome.org/archives/desktop-devel-list/2004-November/msg00693.html,
i.e. the layer insulating apps from the specific hardware) to define
the capabilities and constraints, and user preferences to choose
something within those constraints.

This can be confusing to think about because files like xorg.conf
currently mix the two. But the difference is between setting up the
available resolutions (and perhaps the autoguessed-best resolution for
the current card-monitor pair); and choosing the current resolution from
among those options.

Within the "driver layer" you then want the merge from multiple data
sources (querying the hardware itself, autodetection logic,
factory/oem/local-site overrides) as we were discussing in the earlier
branch of the thread.

It's important to keep distinct these different *kinds* of configuration
or preference. They aren't the same thing. In effect, the historical
situation with the X config file was that you had to change your video
driver to only export one resolution and then the display would use that
resolution. With xrandr, we can export all possible resolutions from the
driver, and then let users choose the one they want.

Anyhow, so the overall situation is quite complex, as we have the chain
of driver setup:
hardware query -> vendor overrides -> oem overrides -> autoprobe logic
-> site overrides -> whatever else

and the chain of user prefs lookup:
site defaults -> user's settings -> site mandatory

Havoc

[David Zeuthen]

Post by Bill Nottingham
Hence, where we're probably going to end up is that kudzu will, at
most, handle things like modprobe.conf aliases for networking;

And when user space can finally control driver binding / per-device
driver options we
can go ahead and kill that cruft which is modprobe.conf and aliases. The
way it works
today, with the kernel automatically binding drivers, is in my view
rather flawed.

It even looks like people are working on this

http://lkml.org/lkml/2004/11/9/330

David

[Bill Nottingham]

Post by David Zeuthen
It even looks like people are working on this
http://lkml.org/lkml/2004/11/9/330

This is fundamentally uninteresting without userspace policy support.

Of course, foisting complication on userspace from the kernel seems
to be the way to go these days, judging by udev. :)

Bill

[David Zeuthen]

Post by Bill Nottingham

Post by David Zeuthen
It even looks like people are working on this
http://lkml.org/lkml/2004/11/9/330

This is fundamentally uninteresting without userspace policy support.

Which is planned to be added upstream in hal - in a nutshell, what is
needed for auto configuration of hardware is some mechanism to store
configuration data about physical and logical devices in a persistent
manner [1] accessible through a unified interface [2]. Once you have
that, it's not really hard to replace existing or write new policy
agents.

Post by Bill Nottingham
Of course, foisting complication on userspace from the kernel seems
to be the way to go these days, judging by udev. :)

Heh, actually one thing I like about udev is the fact that it made
a lot of *existing* bugs and hacks like inserting "sleep 2" visible.
Oh wait, Greg KH already explained this here

http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0769.html

and in surrounding messages :-)

Cheers,
David

[1] : Including the ability to tie configuration to specific device
instances, e.g. if a physical devices lacks a serial number we need
to track the data by connection.

[2] : Meaning that we shouldn't have 1000 different configuration
files in various formats. With a unified interface it becomes
almost trivial to write a "real" device manager, e.g. hal-device-
manager just with real management, for example, "Select MAC
Address", "Select Interface Name" or "Select Driver" buttons for
configuring networking hardware. It's just a simple SetProperty()
method call over D-BUS.

[Bill Nottingham]

Post by David Zeuthen
Which is planned to be added upstream in hal - in a nutshell, what is
needed for auto configuration of hardware is some mechanism to store
configuration data about physical and logical devices in a persistent
manner [1] accessible through a unified interface [2]. Once you have
that, it's not really hard to replace existing or write new policy
agents.

A good chunk of this is per-system, not per device. The main
purpose of most of the aliases these days is to enforce some sort
of reasonable ordering, which is needed in lieu of persistent device
naming [1].

Realistically, all the aliases written by kudzu these days are for is:
a) enforcing ordering among scsi devices
b) enforcing ordering among sound devices
c) allowing network devices to be brought up if the driver isn't already
loaded (which usually means it's been manually removed)
d) parport_serial (its own weirdness)
e) allowing video devices to be loaded on demand

c) and e) could conceivably go away right now.

If you're looking per-device, you can add this sort of ordering/indexing
there, but I'm not sure that's the most efficent.

Post by David Zeuthen

Post by Bill Nottingham
Of course, foisting complication on userspace from the kernel seems
to be the way to go these days, judging by udev. :)

Heh, actually one thing I like about udev is the fact that it made
a lot of *existing* bugs and hacks like inserting "sleep 2" visible.
Oh wait, Greg KH already explained this here
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0769.html
and in surrounding messages :-)

Oh my goodness.

OK, first. 'sleep 2'? Part of the udev stack still is userspace busy
waiting on the kernel. It's not making the hack more visible, it's
just moving it somewhere else.

That's the majority of what udev does... it just merely moves
all the races and oddness to userspace. It's a case of the kernel saying
'here, I don't want to deal with these problems, I'm going to
break your access model based on the deficiences of some buses, have
fun reorienting to fix it.'

And then leaves userspace to clean up the mess.

For example, because of the wonders of udev:

- Take the example of a sound card. You want to restore the volume
on startup.

Under previous configurations, you needed to know the name of the
command to restore sound. You then added it to modules.conf.

Under udev you need to create a dev.d script to run, which means:

- your script needs to know the sysfs layout of the device,
which of course never changes (to avoid running extraneously)
- because you never get a 'this driver is done creating devices'
signal, you need to either
a) sleep a random amount of time
b) run the restore command multiple times

Repeat this scenario for other devices.
How is this progress?

- Say an app wants to use some sort of random device, not
really tied to a piece of hardware.

Under previous configurations, they opened the device, and
either got ENODEV, or continued successfully. [2]

Under udev, either:

a) it works. This means that the driver has been loaded
and udev has already run, hopefully. This means that some
other process:

- has loaded all the device modules. Ergo, every user
has floppy, loop, nvram, etc loaded in nonswappable
kernel memory.
- has made random device nodes for them and trusted
that kmod works. So, what exactly was the point of a dynamic
/dev then?

b) it fails with -ENOENT
Hopefully, that means there's no device. But if
someone decided to remove a module like nvram earlier...?
Then the *app* needs to know what driver to load, and
create its own dev.d script to notify itself that the
device is ready.

I'm sure there can be more examples.

It's true that there are many classes of devices that require
an asynchronous framework to work correctly. I'm not convinced
that adding the same handicaps to all the device types, Harrison
Bergeron-style, is a well thought out design. It's akin to
making apps that use dlopen() or apps that link library dependencies
parse text files for every link libraries because some platforms' linkers
are deficient.

Bill

[1] Yes, I've seen the examples in udev or the stuff proposed by
OSDL. Next joke.
[2] Yeah, I know the device name can change with udev. Doesn't
solve this aspect without patching your apps either.....

[Alan Cox]

Post by Bill Nottingham
- because you never get a 'this driver is done creating devices'
signal, you need to either
a) sleep a random amount of time
b) run the restore command multiple times

A driver is never done, this is hotplug. I can plug in USB audio any time I
like. Now what could be done if this would help (you tell me as guru of
initscripting) is to tell the userspace "the initial device enumeration
is done". In fact in most cases this would be in the standard pci_foo code.

Post by Bill Nottingham
- has made random device nodes for them and trusted
that kmod works. So, what exactly was the point of a dynamic
/dev then?

Nobody in the kernel world ever thought of udev as a "solely dynamic" world
to my knowledge but as a partially dynamic one.

Post by Bill Nottingham
[1] Yes, I've seen the examples in udev or the stuff proposed by
OSDL. Next joke.

Propose a "Carrier grade udev" project ;)

Alan

[Bill Nottingham]

Post by Alan Cox

Post by Bill Nottingham
- because you never get a 'this driver is done creating devices'
signal, you need to either
a) sleep a random amount of time
b) run the restore command multiple times

A driver is never done, this is hotplug. I can plug in USB audio any time I
like. Now what could be done if this would help (you tell me as guru of
initscripting) is to tell the userspace "the initial device enumeration
is done". In fact in most cases this would be in the standard pci_foo code.

Basically, for any ALSA driver, it creates various device nodes; control
nodes, PCM nodes, etc. These device nodes appear to be created in a different
order depending on the driver (or perhaps the udev events are getting
reordered). While the device you use to set the mixer is the control
device, the device isn't actually available until some point later
after various other device nodes are created. So, some sort of
"i'm done with device nodes for this one physical device" signal
would be nice.

Post by Alan Cox

Post by Bill Nottingham
- has made random device nodes for them and trusted
that kmod works. So, what exactly was the point of a dynamic
/dev then?

Nobody in the kernel world ever thought of udev as a "solely dynamic" world
to my knowledge but as a partially dynamic one.

I've seen rumblings that kmod was slated for removal, though, which
means that the only other option would be to load all non-physical
devices unilaterally. This seems subpar.

Bill

[Bill Nottingham]

Post by Jeff Spaleta
As people have already pointed again in this thread... there is a
communication gap in what kudzu wants as a configuration for some
devices.. and what local admin/user wants. Is the hal/network-manager
software stack suppose to provide the missing piece of the puzzle so
that kudzu doesn't have to deal with site specific configs?

It's part of it.

Realistically, the only sort of device that has a lot of site-local
configuration is a network card; for most other things you don't care.

Hence, where we're probably going to end up is that kudzu will, at
most, handle things like modprobe.conf aliases for networking;
actual config will be handled by something like NetworkManager,
and system-config-network.

Bill

[Michael Favia]

Post by Bill Nottingham

Post by Jeff Spaleta

Post by Bill Nottingham
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

While the addition and removal of the hardware that is present makes
sense, the unconfiguration (read: data loss) of that hardware's profile
does not. Is there not (or shouldn't there be) a mechanism to cache the
configuration of the devices so that the customizations made to them is
retained when they are plugged back in? This system would provide the
benefits of both models (speed, statefulness) without the draw back of
either (boot speed, digital decay) IMO.

Should the user really want the device to "reset" when it is
unplugged/poweredoff at restart and then reinstalled later would be to
somehow manually clear the cache. Which is a much less frequent activity
i hope.

[Bill Nottingham]

Post by Bill Nottingham

Post by Jeff Spaleta
Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Note that *this* part has actually been in rawhide since the middle
of December...

Bill

[Paul]

Hi,

Post by Bill Nottingham

Post by Jeff Spaleta
Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Excellent. Now to get my system to actually allow me to install rpms
without constantly giving me preun and postun errors!

rpm --vv isn't being very helpful...

TTFN

Paul
--
"He's not the Messiah, he's a very naughty boy!"
- Life of Brian, Monty Python
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050103/bc515db7/attachment-0002.bin

[Dax Kelson]

Post by Bill Nottingham

Post by Jeff Spaleta

Post by Bill Nottingham
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Not good for many situations. For example:

Currently my wireless NIC (Intel 2200BG) uses a out-of-kernel driver.

Whenever Fedora releases an updated kernel and I reboot kudzu wants to
remove my wireless NIC as I haven't recompiled my driver yet.

I DO NOT want kudzu removing the configuration (very very long WEP keys,
and other hand entered wireless settings).

The behavior, as described, is unacceptable IMHO.

Dax Kelson
Guru Labs

[Jeff Spaleta]

Post by Bill Nottingham
Yes. Hence, a large shaking out period.

fun! I hope that shaking out period includes an effort to make kudzu
aware of local changes so that local configurations can be restored
instead of kudzu defaults when the hardware is found again. Auto
removal isn't a bad thing... as long as there is a way to save and
restore state information so kudzu's defaults are not relied on over
and over again.

As people have already pointed again in this thread... there is a
communication gap in what kudzu wants as a configuration for some
devices.. and what local admin/user wants. Is the hal/network-manager
software stack suppose to provide the missing piece of the puzzle so
that kudzu doesn't have to deal with site specific configs?

-jef"as much fun as a dental visit"spaleta

[Michael Favia]

Post by Bill Nottingham

Post by Jeff Spaleta

Post by Bill Nottingham
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

While the addition and removal of the hardware that is present makes
sense, the unconfiguration (read: data loss) of that hardware's profile
does not. Is there not (or shouldn't there be) a mechanism to cache the
configuration of the devices so that the customizations made to them is
retained when they are plugged back in? This system would provide the
benefits of both models (speed, statefulness) without the draw back of
either (boot speed, digital decay) IMO.

Should the user really want the device to "reset" when it is
unplugged/poweredoff at restart and then reinstalled later would be to
somehow manually clear the cache. Which is a much less frequent activity
i hope.

[Bill Nottingham]

Post by Bill Nottingham

Post by Jeff Spaleta
Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Note that *this* part has actually been in rawhide since the middle
of December...

Bill

[Bill Nottingham]

Post by Jeff Spaleta

Post by Bill Nottingham
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

Bill

[Roland McGrath]

Post by Bill Nottingham

Post by Jeff Spaleta

Post by Bill Nottingham
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

This is never what I want. I was damn annoyed the other day when someone
with less clue accidentally hit return and let it remove some configuration.
That is, it's never what I want when there is actual software configuration
involved, not just presence-and-flavor-of-the-hardware configuration.
It would be great if it corrected the modprobe aliases for the new NIC
without me thinking about it. It really sucked some hindparts that it
removed ifcfg-eth0 without a trace and then asked me how I wanted to
configure the fresh one from scratch after it had added the different eth0
alias to modprobe.conf for me. When the sequence of questions was "Shall I
remove your hand-tweaked configuration and leave no backup record of it?"
followed by "Would you like to tweak this new configuration by hand from
memory, or else have it not work at all if you do nothing special right now?",
this was suboptimal. When those questions are answered "yes" by default
with no interacton, this is unacceptable.

[Alan Cox]

Post by Roland McGrath
with less clue accidentally hit return and let it remove some configuration.
That is, it's never what I want when there is actual software configuration
involved, not just presence-and-flavor-of-the-hardware configuration.

Ditto. My laptop has a docking station that kudzu simply doesn't grok. The
fact I can tell kudzu to just leave all existing configuration behind is
pretty essential since every boot docked or undocked it discovers new
hardware or removed hardware.

Alan

[Sam Varshavchik]

Post by Alan Cox

Post by Roland McGrath
with less clue accidentally hit return and let it remove some configuration.
That is, it's never what I want when there is actual software configuration
involved, not just presence-and-flavor-of-the-hardware configuration.

Ditto. My laptop has a docking station that kudzu simply doesn't grok. The
fact I can tell kudzu to just leave all existing configuration behind is
pretty essential since every boot docked or undocked it discovers new
hardware or removed hardware.

Same thing happens with garden-variety PCMCIA cards or anything attached to
the USB port, if you change run levels.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050103/81b0c7ec/attachment.bin

[Matthew Miller]

Post by Alan Cox
Ditto. My laptop has a docking station that kudzu simply doesn't grok. The
fact I can tell kudzu to just leave all existing configuration behind is
pretty essential since every boot docked or undocked it discovers new
hardware or removed hardware.

rpm -e kudzu

:)

[Owen Taylor]

Post by Alan Cox

Post by Roland McGrath
with less clue accidentally hit return and let it remove some configuration.
That is, it's never what I want when there is actual software configuration
involved, not just presence-and-flavor-of-the-hardware configuration.

Ditto. My laptop has a docking station that kudzu simply doesn't grok. The
fact I can tell kudzu to just leave all existing configuration behind is
pretty essential since every boot docked or undocked it discovers new
hardware or removed hardware.

But you can't possibly believe that this is the right behavior??? To
have to manually interact with the startup every time to keep it from
deleting useful information?

If there is information that needs to be kept around per-device, then it
should
be stored keyed to the device even when the device isn't there.

(WEP key isn't one of those... that's per-network not per network-device
and shouldn't
be in the device configuration at all; I think NetworkManager handles it
correctly.)

Regards,
Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050104/15524f82/attachment.bin

[Alan Cox]

Post by Owen Taylor
But you can't possibly believe that this is the right behavior??? To
have to manually interact with the startup every time to keep it from
deleting useful information?

Its definitely not right, it needs to keep the stuff.

Post by Owen Taylor
If there is information that needs to be kept around per-device, then it
should be stored keyed to the device even when the device isn't there.

Agreed. That would clean up a lot of the mess I see.

Post by Owen Taylor
(WEP key isn't one of those... that's per-network not per network-device
and shouldn't
be in the device configuration at all; I think NetworkManager handles it
correctly.)

Except when it isn't. Think about wireless in docking stations, wireless USB
ports in hotels ..

[Arjan van de Ven]

Post by Alan Cox
Except when it isn't. Think about wireless in docking stations, wireless USB
ports in hotels ..

it's a per *network* (well ESSID I guess) property for sure. Not per
card... I think the word "network" is a bit ambigious :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050104/86c5cedd/attachment.bin

[Dan Williams]

Post by Alan Cox
Except when it isn't. Think about wireless in docking stations, wireless USB
ports in hotels ..

If the kernel recognizes it as a wireless device, and its exposed sanely
in sysfs (*cough* PCMCIA-hates-sysfs-somebody-needs-to-integrate-adams-
patches *cough*) then NetworkManager can use it without configuration.
This is purely a kernel+driver+udev problem.

Dan

[Rodd Clarkson]

Post by Dan Williams
If the kernel recognizes it as a wireless device, and its exposed sanely
in sysfs (*cough* PCMCIA-hates-sysfs-somebody-needs-to-integrate-adams-
patches *cough*) then NetworkManager can use it without configuration.

Dan,

Does this mean there is a patch to get hal to set the capabilities of
PCMCIA wireless cards so they work with NetworkManager?

Can I help test it ;-]


Rodd

PS. You may recall doing to work (to help me) regarding this pre FC3.

[Dan Williams]

Post by Rodd Clarkson

Post by Dan Williams
If the kernel recognizes it as a wireless device, and its exposed sanely
in sysfs (*cough* PCMCIA-hates-sysfs-somebody-needs-to-integrate-adams-
patches *cough*) then NetworkManager can use it without configuration.

Dan,
Does this mean there is a patch to get hal to set the capabilities of
PCMCIA wireless cards so they work with NetworkManager?
Can I help test it ;-]

Hi Rodd!

Well, the patch has been there for a while, but I'm still not sure it
fixes your problem of the PCMCIA-card-on-PCI-card thingy...

Dan

[Eli]

Post by Alan Cox

Post by Owen Taylor
But you can't possibly believe that this is the right behavior??? To
have to manually interact with the startup every time to keep it from
deleting useful information?

Its definitely not right, it needs to keep the stuff.

Definitely. I have a Toshiba notebook that seems to detect a different video
card about the time I upgrade the kernel... and then sets the resolution to
800x600, despite this being a 1024x768 screen.

Grrr.

Eli

[Bill Nottingham]

Post by Eli

Post by Alan Cox
Its definitely not right, it needs to keep the stuff.

Definitely. I have a Toshiba notebook that seems to detect a different video
card about the time I upgrade the kernel... and then sets the resolution to
800x600, despite this being a 1024x768 screen.

OK, I believe this is because when s-c-display is told to change the
card, it tries to probe for the monitor too, and if that fails,
it defaults to something generic.

This can be solved by:

a) only changing the card
b) fixing X to do something sane with the monitor definition

Bill

[Dax Kelson]

Post by Owen Taylor
(WEP key isn't one of those... that's per-network not per network-device
and shouldn't
be in the device configuration at all; I think NetworkManager handles it
correctly.)

Does NetworkManager handle non-ESSID broadcasting access points yet?

When I last looked (awhile ago) it didn't, making it not usable for me.

Dax

[Dan Williams]

Post by Dax Kelson

Post by Owen Taylor
(WEP key isn't one of those... that's per-network not per network-device
and shouldn't
be in the device configuration at all; I think NetworkManager handles it
correctly.)

Does NetworkManager handle non-ESSID broadcasting access points yet?

Yes, look for the "Other Wireless Network..." item in the applet's menu.
After you connect the first time, it will cache the MAC address of the
access point and recognize it (thereby putting it in the menu) from then
on.

Dan

[Sam Varshavchik]

Post by Alan Cox

Post by Roland McGrath
with less clue accidentally hit return and let it remove some configuration.
That is, it's never what I want when there is actual software configuration
involved, not just presence-and-flavor-of-the-hardware configuration.

Ditto. My laptop has a docking station that kudzu simply doesn't grok. The
fact I can tell kudzu to just leave all existing configuration behind is
pretty essential since every boot docked or undocked it discovers new
hardware or removed hardware.

Same thing happens with garden-variety PCMCIA cards or anything attached to
the USB port, if you change run levels.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050103/81b0c7ec/attachment-0002.bin

[Matthew Miller]

Post by Alan Cox
Ditto. My laptop has a docking station that kudzu simply doesn't grok. The
fact I can tell kudzu to just leave all existing configuration behind is
pretty essential since every boot docked or undocked it discovers new
hardware or removed hardware.

rpm -e kudzu

:)

[Alan Cox]

Post by Roland McGrath
with less clue accidentally hit return and let it remove some configuration.
That is, it's never what I want when there is actual software configuration
involved, not just presence-and-flavor-of-the-hardware configuration.

Ditto. My laptop has a docking station that kudzu simply doesn't grok. The
fact I can tell kudzu to just leave all existing configuration behind is
pretty essential since every boot docked or undocked it discovers new
hardware or removed hardware.

Alan

[Roberto Peon]

This sounds good.. And generally, configuration is tiny, so keeping it around
isn't generally a problem from that end.

-Roberto JP

Post by Michael Favia

Post by Bill Nottingham

Post by Jeff Spaleta

Post by Bill Nottingham
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

While the addition and removal of the hardware that is present makes
sense, the unconfiguration (read: data loss) of that hardware's profile
does not. Is there not (or shouldn't there be) a mechanism to cache the
configuration of the devices so that the customizations made to them is
retained when they are plugged back in? This system would provide the
benefits of both models (speed, statefulness) without the draw back of
either (boot speed, digital decay) IMO.
Should the user really want the device to "reset" when it is
unplugged/poweredoff at restart and then reinstalled later would be to
somehow manually clear the cache. Which is a much less frequent activity
i hope.
--
Michael Favia michael.favia at insitesinc.com
Insites Incorporated http://michael.insitesinc.com
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Roberto Peon]

Disagreement.

I have custom configuration for my audio card (custom alsa config), and my
video capture card (have to specify tuner and firmware location) as well.

-Roberto JP

Post by Bill Nottingham

Post by Jeff Spaleta
As people have already pointed again in this thread... there is a
communication gap in what kudzu wants as a configuration for some
devices.. and what local admin/user wants. Is the hal/network-manager
software stack suppose to provide the missing piece of the puzzle so
that kudzu doesn't have to deal with site specific configs?

It's part of it.
Realistically, the only sort of device that has a lot of site-local
configuration is a network card; for most other things you don't care.
Hence, where we're probably going to end up is that kudzu will, at
most, handle things like modprobe.conf aliases for networking;
actual config will be handled by something like NetworkManager,
and system-config-network.
Bill
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Bill Nottingham]

Post by Roberto Peon
Disagreement.
I have custom configuration for my audio card (custom alsa config), and my
video capture card (have to specify tuner and firmware location) as well.

kudzu doesn't touch these, unless I'm missing something.

Bill

[Colin Walters]

Post by Roberto Peon
Disagreement.
I have custom configuration for my audio card (custom alsa config),

What do you configure? Or are you just working around bugs?

Post by Roberto Peon
and my
video capture card (have to specify tuner and firmware location) as well.

That just sounds like you're working around a bug. Doesn't it work to
put the firmware in /lib/firmware?

[Bill Nottingham]

Post by Roberto Peon
Disagreement.
I have custom configuration for my audio card (custom alsa config), and my
video capture card (have to specify tuner and firmware location) as well.

kudzu doesn't touch these, unless I'm missing something.

Bill

[Roland McGrath]

Post by Havoc Pennington
IMO the root problem if this breaks is mixing of autoprobe data with
user configuration. We need to fix it by unmixing those things, not by
breaking autoprobe or losing people's config files.

Sure. But actually my problem doesn't need this sort of general solution.
Rather, it needs the separation of what's kudzu's bidness and what ain't,
which has already been mentioned. That is, for the case of network cards,
I want to have custom configuration for "eth0" and when I swap out the
motherboard and there is a different NIC flavor now, kudzu is damn helpful
in updating the idea of what driver "eth0" means and I need it for that.
So if that part of it is separated out into network-manager or whatever,
I would just have that configured not to change anything automagically and
be happy (disable network-manager, I guess, since I don't know what it is).

[Roberto Peon]

My point is/was simply that there is custom configuration of/for modules and
hardware that is not ethernet related.

-Roberto

Post by Bill Nottingham

Post by Roberto Peon
Disagreement.
I have custom configuration for my audio card (custom alsa config), and my
video capture card (have to specify tuner and firmware location) as well.

kudzu doesn't touch these, unless I'm missing something.
Bill
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Roberto Peon]

I honestly don't remember what the alsa config does anymore, since it has been
humming along nicely for a while now.

The capture card came out with a new tuner, and the module authors took a bit
to get autodetecting support for it into the module.

The firmware comes from a different party (i.e. the hardware manufacturer who
doesn't provide a linux driver-- suprise suprise), and so I have an init-script
extract it from the latest available driver (i.e. out of an self-extracting
(win32) archive).

Since I tend towards the bleeding edge of hardware and software, working around
bugs is just something I often do.

-Roberto JP

Post by Colin Walters

Post by Roberto Peon
Disagreement.
I have custom configuration for my audio card (custom alsa config),

What do you configure? Or are you just working around bugs?

Post by Roberto Peon
and my
video capture card (have to specify tuner and firmware location) as well.

That just sounds like you're working around a bug. Doesn't it work to
put the firmware in /lib/firmware?
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Rahul Sundaram]

Hi

Post by Bill Nottingham
Of course, foisting complication on userspace from
the kernel seems
to be the way to go these days, judging by udev. :)

well, the alternative called devfs in the kernel see,s
to be totally broken and unmaintained.

=====
Regards
Rahul Sundaram



__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

[Rahul Sundaram]

Hi

Post by Havoc Pennington
http://www.gnome.org/projects/gconf/plans.html
but I believe it works fine now once you figure it
out.

I see you throw up that link on many discussions
related to gconf but is someone working on that or
plans to?

I have also heard discussions about a fd.o system to
replace this one
(newconf?). has there been any progress in that front ?

=====
Regards
Rahul Sundaram



__________________________________
Do you Yahoo!?
All your favorites on one personal page ? Try My Yahoo!
http://my.yahoo.com

[Havoc Pennington]

Post by Rahul Sundaram
I see you throw up that link on many discussions
related to gconf but is someone working on that or
plans to?

Not that I know of. That's why I keep posting the link ;-)
Someday someone will read it and say "oh, I should do that"

Post by Rahul Sundaram
I have also heard discussions about a fd.o system to
replace this one
(newconf?). has there been any progress in that front ?

D-BUS is moving along nicely, which would give you the basic building
block.

The "future gconf" described at the link I posted *should* be a fair bit
easier to implement than current gconf is, and less code in the end.

Havoc

[Rahul Sundaram]

Hi

Post by Havoc Pennington
Not that I know of. That's why I keep posting the
link ;-)
Someday someone will read it and say "oh, I should
do that"

I believe the current one is written by you. In that
case you are probably the most suitable person to do
it if you have the time..

Post by Havoc Pennington
D-BUS is moving along nicely, which would give you
the basic building
block.

I dont see how a more universal registry of settings
is going to use an IPC mechanism as a building block.
Would you please care to expand on that. is this
future plan documented somewhere just like the gconf
link :-).

Post by Havoc Pennington
The "future gconf" described at the link I posted
*should* be a fair bit
easier to implement than current gconf is, and less
code in the end.

I guess that means you expect a complete rewrite. I
believe a newer version of KDE and gnome which breaks
binary compatibility is the crucial point to push thru
fundamental sub systems like dbus and gstreamer for
example. I would love to see a universal gconf like
system being adopted by next major versions of the
DE's

Also useful would be a discussion to create a fd.o
system as kparts/bonobo replacement. would dbus fit
the basic needs here?

Since KDE versions are released in sync with QT, the
next major version of KDE is likely to be released
before Gnome (QT 4 beta 1 has already been released)
and hence this has to taken into consideration for all
such discussions

=====
Regards
Rahul Sundaram



__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

[Havoc Pennington]

Post by Rahul Sundaram
I believe the current one is written by you. In that
case you are probably the most suitable person to do
it if you have the time..

Sure, but I don't. ;-) Someone at Red Hat might eventually, but it just
depends on the priority queue.

Post by Rahul Sundaram

Post by Havoc Pennington
D-BUS is moving along nicely, which would give you
the basic building
block.

I dont see how a more universal registry of settings
is going to use an IPC mechanism as a building block.
Would you please care to expand on that. is this
future plan documented somewhere just like the gconf
link :-).

It's at the gconf link, gconf is IPC-based.

There are two basic parts to config system of the future in my view, one
is a client library that manages schemas on the client side (loading
fallbacks from them, locating the schema for a particular setting).
The other is a daemon that provides the current settings, but has
nothing to do with schemas. This removes the major reasons that gconfd
is complicated internally and the major reasons that admins and
programmers get confused about it. Also gets rid of the RPM %post
scriptlets that run gconftool. In short we make schemas something that
are dealt with transparently inside the prefs library by not having the
idea of "installing" them.

Post by Rahul Sundaram

Post by Havoc Pennington
The "future gconf" described at the link I posted
*should* be a fair bit
easier to implement than current gconf is, and less
code in the end.

I guess that means you expect a complete rewrite.

Maybe eventually but it's not strictly required in the short term; you
could recycle a bunch of code from current gconf. In fact you may want
to recycle the file format parsers so people don't lose their settings.
Though the file format sucks, it most likely isn't worth fixing since
nobody reads/writes it directly anyhow.

Post by Rahul Sundaram
believe a newer version of KDE and gnome which breaks
binary compatibility is the crucial point to push thru
fundamental sub systems like dbus and gstreamer for
example. I would love to see a universal gconf like
system being adopted by next major versions of the
DE's

You don't have to break ABI really since you can add a new ABI and keep
but deprecate the old one.

I'm not really optimistic that a config system spanning GNOME/KDE can be
done; that's why I phrase the goal as writing a "shareable" config
system. The reason is that KConfig and GConf are just a little bit too
different. So to me it will be hard to get up-front agreement on what
the system should be like, the only real possibility is to write a
system that everyone could use in principle, and then let it compete de
facto.

Post by Rahul Sundaram
Also useful would be a discussion to create a fd.o
system as kparts/bonobo replacement. would dbus fit
the basic needs here?

You have to separate three things:
- IPC
- component system
- widget/control embedding

A problem with Bonobo was trying to do all three of those at once and
being fuzzy about the use cases for each one and how the three things
are different.

D-BUS is IPC only. Component systems look like they are going away in
favor of plugin systems (as in Eclipse) and sufficiently powerful object
systems (as in C#). You really want to be able to use multiple IPC
systems (SOAP, D-BUS, XML-RPC, or whatever) depending on your needs, so
you want to keep that orthogonal to the object/plugin system.

Widget embedding is something we could implement over any IPC system,
really the hard parts have nothing to do with the IPC system and
everything to do with what you send over it. i.e. reconciling the
semantics of Qt vs. GTK+ and what they expect from an embedded control.
The more capabilities you have (such as menu merge) the more potential
for semantic mismatch.

Havoc

[Bill Nottingham]

In tomorrow's rawhide should be kudzu-1.105-1 and initscripts-8.02-1.
These implement various changes for speeding up bootup some:

- removal of initlog and minilogd

Basically, the things that were logged before syslog started were
generally uninteresting, and it added a surprising amount of delay
to the bootup. There should/will be a better mechanism
for recording whether services start succesfully added at some point
later.

- hack to allow kudzu to read the devices from a socket from kmodule

This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

The combination of these should speed up the boot a somewhat
noticeable amount of time compared to stock FC3. Currently, there
are the following issues:

- text boot is now more noisy

initlog did hide some spew from various services; this needs cleaned up.

- things that try to call initlog will simply fail

openssh and Canna should be fixed. Other things will need fixed.
I suppose a initlog wrapper that accepts the same syntax and just
'execs' may be useful, but it's probably best to do a clean break
and see what happens.

Bill

[Jeff Spaleta]

Post by Bill Nottingham
- hack to allow kudzu to read the devices from a socket from kmodule
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

-jef

[Roland McGrath]

Post by Bill Nottingham

Post by Jeff Spaleta

Post by Bill Nottingham
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

This is never what I want. I was damn annoyed the other day when someone
with less clue accidentally hit return and let it remove some configuration.
That is, it's never what I want when there is actual software configuration
involved, not just presence-and-flavor-of-the-hardware configuration.
It would be great if it corrected the modprobe aliases for the new NIC
without me thinking about it. It really sucked some hindparts that it
removed ifcfg-eth0 without a trace and then asked me how I wanted to
configure the fresh one from scratch after it had added the different eth0
alias to modprobe.conf for me. When the sequence of questions was "Shall I
remove your hand-tweaked configuration and leave no backup record of it?"
followed by "Would you like to tweak this new configuration by hand from
memory, or else have it not work at all if you do nothing special right now?",
this was suboptimal. When those questions are answered "yes" by default
with no interacton, this is unacceptable.

[Roberto Peon]

This sounds good.. And generally, configuration is tiny, so keeping it around
isn't generally a problem from that end.

-Roberto JP

Post by Michael Favia

Post by Bill Nottingham

Post by Jeff Spaleta

Post by Bill Nottingham
This allows hardware probing to be done only once; the specifics of
where/how kudzu is run in this setup may be tweaked slightly - the
initscript may be moved. kudzu also runs without interaction
now, and just does the configuration of whatever it finds.

Does this mean kudzu will remove and unconfigure whatever it doesnt
find without interaction as well?

Yes. Hence, a large shaking out period.

While the addition and removal of the hardware that is present makes
sense, the unconfiguration (read: data loss) of that hardware's profile
does not. Is there not (or shouldn't there be) a mechanism to cache the
configuration of the devices so that the customizations made to them is
retained when they are plugged back in? This system would provide the
benefits of both models (speed, statefulness) without the draw back of
either (boot speed, digital decay) IMO.
Should the user really want the device to "reset" when it is
unplugged/poweredoff at restart and then reinstalled later would be to
somehow manually clear the cache. Which is a much less frequent activity
i hope.
--
Michael Favia michael.favia at insitesinc.com
Insites Incorporated http://michael.insitesinc.com
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Roberto Peon]

Disagreement.

I have custom configuration for my audio card (custom alsa config), and my
video capture card (have to specify tuner and firmware location) as well.

-Roberto JP

Post by Bill Nottingham

Post by Jeff Spaleta
As people have already pointed again in this thread... there is a
communication gap in what kudzu wants as a configuration for some
devices.. and what local admin/user wants. Is the hal/network-manager
software stack suppose to provide the missing piece of the puzzle so
that kudzu doesn't have to deal with site specific configs?

It's part of it.
Realistically, the only sort of device that has a lot of site-local
configuration is a network card; for most other things you don't care.
Hence, where we're probably going to end up is that kudzu will, at
most, handle things like modprobe.conf aliases for networking;
actual config will be handled by something like NetworkManager,
and system-config-network.
Bill
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Roland McGrath]

Post by Havoc Pennington
IMO the root problem if this breaks is mixing of autoprobe data with
user configuration. We need to fix it by unmixing those things, not by
breaking autoprobe or losing people's config files.

Sure. But actually my problem doesn't need this sort of general solution.
Rather, it needs the separation of what's kudzu's bidness and what ain't,
which has already been mentioned. That is, for the case of network cards,
I want to have custom configuration for "eth0" and when I swap out the
motherboard and there is a different NIC flavor now, kudzu is damn helpful
in updating the idea of what driver "eth0" means and I need it for that.
So if that part of it is separated out into network-manager or whatever,
I would just have that configured not to change anything automagically and
be happy (disable network-manager, I guess, since I don't know what it is).

[Roberto Peon]

My point is/was simply that there is custom configuration of/for modules and
hardware that is not ethernet related.

-Roberto

Post by Bill Nottingham

Post by Roberto Peon
Disagreement.
I have custom configuration for my audio card (custom alsa config), and my
video capture card (have to specify tuner and firmware location) as well.

kudzu doesn't touch these, unless I'm missing something.
Bill
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list