[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: some changes for (slightly) faster boot



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]