Hi guys,
I just noticed CONFIG_DRM_I915_KMS is enabled for x86-64.
This should never be the case, as anyone who built defconfig kernels before,
will now get KMS enabled when really they need to have done userspace upgrades.
KMS should default to n in the upstream kernel, for at least 4-5 years.
Dave.
* Dave Airlie <[email protected]> wrote:
> Hi guys,
>
> I just noticed CONFIG_DRM_I915_KMS is enabled for x86-64.
>
> This should never be the case, as anyone who built defconfig
> kernels before, will now get KMS enabled when really they need to
> have done userspace upgrades.
I've yet to see such a bugreport.
But i dont have particularly strong feelings about defconfigs: less
than 1% of all kernel developers use them - which transforms into
less than 0.01% of all Linux users.
KMS is off by default in 'make oldconfig', right? That's all that
matters really.
defconfigs _do_ change and there was never a compatibility rule for
defconfigs. Arch defconfig is more of a signal towards what the
architecture maintainers consider sane and supportable (or
desirable) defaults - and it is also what developers working on
arch/x86 should consider as the main thrust of features.
> KMS should default to n in the upstream kernel, for at least 4-5
> years.
That's an extremely long period of migration. I also think it's
unreasonable: we dont want to draw out the migration from
DRI1+user-space-mode-setting to DRI2+KMS that long. KMS should have
been implemented and made the default 4-5 years _ago_ i think.
KMS is the sane design for graphics and i'd go as far as to consider
user-space mode setting an outright _bug_. It look a long time to
fix but now lets look forward and fix all the bugs in KMS, ASAP ...
Ingo
On Mon, Apr 27, 2009 at 6:39 PM, Ingo Molnar <[email protected]> wrote:
>
> * Dave Airlie <[email protected]> wrote:
>
>> Hi guys,
>>
>> I just noticed CONFIG_DRM_I915_KMS is enabled for x86-64.
>>
>> This should never be the case, as anyone who built defconfig
>> kernels before, will now get KMS enabled when really they need to
>> have done userspace upgrades.
>
> I've yet to see such a bugreport.
>
> But i dont have particularly strong feelings about defconfigs: less
> than 1% of all kernel developers use them - which transforms into
> less than 0.01% of all Linux users.
>
> KMS is off by default in 'make oldconfig', right? That's all that
> matters really.
My main worry is distro configs going forward, where they pull something
from defconfig, granted I've no idea if that'll happen, maybe distro kernel
maintainers are smarter than I give them credit for :-)
> defconfigs _do_ change and there was never a compatibility rule for
> defconfigs. Arch defconfig is more of a signal towards what the
> architecture maintainers consider sane and supportable (or
> desirable) defaults - and it is also what developers working on
> arch/x86 should consider as the main thrust of features.
>
> That's an extremely long period of migration. I also think it's
> unreasonable: we dont want to draw out the migration from
> DRI1+user-space-mode-setting to DRI2+KMS that long. KMS should have
> been implemented and made the default 4-5 years _ago_ i think.
>
> KMS is the sane design for graphics and i'd go as far as to consider
> user-space mode setting an outright _bug_. It look a long time to
> fix but now lets look forward and fix all the bugs in KMS, ASAP ...
Its mainly for things like Andrews Vaio, people will not expect a new kernel
to take out any current userspace, its a pain, but we assume distros + people
who compile their own kernels will know what userspace exists on their
machines and other will get the least surprise.
Dave.
>
> ? ? ? ?Ingo
>
On Mon, 2009-04-27 at 10:39 +0200, Ingo Molnar wrote:
> * Dave Airlie <[email protected]> wrote:
>
> > Hi guys,
> >
> > I just noticed CONFIG_DRM_I915_KMS is enabled for x86-64.
> >
> > This should never be the case, as anyone who built defconfig
> > kernels before, will now get KMS enabled when really they need to
> > have done userspace upgrades.
>
> I've yet to see such a bugreport.
Whenever I accidentally enable KMS I get a dead X (happens way more
often that I'd like to), I blame this on the ubuntu Xorg packages, but
can't be arsed to fix it myself -- hopefully the kinky koala will fix
stuff, but who knows.
Hello,
Dave Airlie wrote:
> My main worry is distro configs going forward, where they pull
> something from defconfig, granted I've no idea if that'll happen,
> maybe distro kernel maintainers are smarter than I give them credit
> for :-)
We're probably as dumb as or even dumber than you give credit for but
we do have testing cycles in place to compensate for it, so I don't
think distros-might-screw-up needs to be a concern when deciding what
gets turned on in defconfig. :-)
I think defconfig should enable options such that it shows where
upstream kernel is headed, so FWIW +1 for KMS from me.
Thanks.
--
tejun
On Tue, Apr 28, 2009 at 1:40 AM, Peter Zijlstra <[email protected]> wrote:
> On Mon, 2009-04-27 at 10:39 +0200, Ingo Molnar wrote:
>> * Dave Airlie <[email protected]> wrote:
>>
>> > Hi guys,
>> >
>> > I just noticed CONFIG_DRM_I915_KMS is enabled for x86-64.
>> >
>> > This should never be the case, as anyone who built defconfig
>> > kernels before, will now get KMS enabled when really they need to
>> > have done userspace upgrades.
>>
>> I've yet to see such a bugreport.
>
> Whenever I accidentally enable KMS I get a dead X (happens way more
> often that I'd like to), I blame this on the ubuntu Xorg packages, but
> can't be arsed to fix it myself -- hopefully the kinky koala will fix
> stuff, but who knows.
Well you can't really blame anyone else for it, since you have to put
the code upstream
in the kernel before you can release drivers that use it for distros to package.
So it would be impossible for any distro to have shipped kms drivers in a useful
fashion before KMS is actually in the kernel.
Dave.
On Tue, 28 Apr 2009, Tejun Heo wrote:
>
> I think defconfig should enable options such that it shows where
> upstream kernel is headed, so FWIW +1 for KMS from me.
I'd actually love to get rid of the stupid defconfig's entirely. They've
lost pretty much all relevance over the years, except for specific cases
where you might have defconfigs that are for specific platforms.
IOW, the embedded kind of "per-platform defconfig" at lest is a useful
starting point. But even there I'm not 100% sure that it makes sense to
pollute the kernel source tree with them - they mess up things like
git grep PREVENT_FIRMWARE_BUILD
horribly.
IOW, they're likely to be more pain than they are worth. And they really
aren't useful starting points for normal people (who are probably better
off starting with their distro kernel config) or likely even for most
kernel developers (who hopefully have noticed that they can install a
per-machine defconfig in /etc/kernel-config and forget about it).
I'd love to just delete them all.
Linus
* Linus Torvalds <[email protected]> wrote:
> On Tue, 28 Apr 2009, Tejun Heo wrote:
> >
> > I think defconfig should enable options such that it shows where
> > upstream kernel is headed, so FWIW +1 for KMS from me.
>
> I'd actually love to get rid of the stupid defconfig's entirely.
> They've lost pretty much all relevance over the years, except for
> specific cases where you might have defconfigs that are for
> specific platforms.
Yes, exactly. That is the main reason why i NAK-ed a patchset a year
ago that would have increased the number of defconfigs on x86
dramatically:
http://lkml.org/lkml/2008/2/25/86
The defconfig still has some very minimal meaning: i use it for
example when i create a default config for a new box. It gives a
reasonable default and then i double-check the lsmod output against
the .config and add one or two more drivers. [would be nice to have
that all automatic btw. - a 'make config-for-this-hardware' type of
kbuild/kconfig thing.]
It is also a good 'middle-ground' config for tests. My tests first
do a 32-bit defconfig, then a 64-bit defconfig, then allno, allyes,
allmod. The defconfig builds quickly so often i can see problems
based on those first iterations already.
Ingo
On Tue, 2009-04-28 at 11:54 +1000, Dave Airlie wrote:
> On Tue, Apr 28, 2009 at 1:40 AM, Peter Zijlstra <[email protected]> wrote:
> > On Mon, 2009-04-27 at 10:39 +0200, Ingo Molnar wrote:
> >> * Dave Airlie <[email protected]> wrote:
> >>
> >> > Hi guys,
> >> >
> >> > I just noticed CONFIG_DRM_I915_KMS is enabled for x86-64.
> >> >
> >> > This should never be the case, as anyone who built defconfig
> >> > kernels before, will now get KMS enabled when really they need to
> >> > have done userspace upgrades.
> >>
> >> I've yet to see such a bugreport.
> >
> > Whenever I accidentally enable KMS I get a dead X (happens way more
> > often that I'd like to), I blame this on the ubuntu Xorg packages, but
> > can't be arsed to fix it myself -- hopefully the kinky koala will fix
> > stuff, but who knows.
>
> Well you can't really blame anyone else for it, since you have to put
> the code upstream
> in the kernel before you can release drivers that use it for distros to package.
>
> So it would be impossible for any distro to have shipped kms drivers in a useful
> fashion before KMS is actually in the kernel.
Can't the driver detect KMS and use it when present? In that case they
could just ship a KMS capable driver that works either way.
Anyway, I'm sure it'll all sort itself out.
On Mon, 27 Apr 2009, Linus Torvalds wrote:
> On Tue, 28 Apr 2009, Tejun Heo wrote:
>>
>> I think defconfig should enable options such that it shows where
>> upstream kernel is headed, so FWIW +1 for KMS from me.
>
> I'd actually love to get rid of the stupid defconfig's entirely. They've
> lost pretty much all relevance over the years, except for specific cases
> where you might have defconfigs that are for specific platforms.
>
> IOW, the embedded kind of "per-platform defconfig" at lest is a useful
> starting point. But even there I'm not 100% sure that it makes sense to
> pollute the kernel source tree with them - they mess up things like
>
> git grep PREVENT_FIRMWARE_BUILD
>
> horribly.
>
> IOW, they're likely to be more pain than they are worth. And they really
> aren't useful starting points for normal people (who are probably better
> off starting with their distro kernel config) or likely even for most
> kernel developers (who hopefully have noticed that they can install a
> per-machine defconfig in /etc/kernel-config and forget about it).
>
> I'd love to just delete them all.
as a end-user creating my own configs, I use the defaults as a guide to
understand when something moves from "we think it's a good idea" to
"things really need this"
there's a _lot_ of stuff that goes in that is useful only is some
situations, and the help text frequently doesn't help understanding what's
really needed vs what the author of that feature _thinks_ is really needed
(containers are a perfect example, they aren't needed in 99% of current
systems, but it's actually _hard_ to really disable them completely)
you mention starting from a distro config, but most distro configs have a
_huge_ number of things enabled that aren't needed for any particular box.
right now it's significantly faster to start with a defconfig and enable
hardware drivers than it is to start with a distro config and disable
things. If a tool was available to detect the hardware and create a
config tailored for the box, this use for a default config would go away
David Lang
On Tue, 28 Apr 2009 09:32:22 +0200
Peter Zijlstra <[email protected]> wrote:
> On Tue, 2009-04-28 at 11:54 +1000, Dave Airlie wrote:
> > On Tue, Apr 28, 2009 at 1:40 AM, Peter Zijlstra
> > <[email protected]> wrote:
> > > On Mon, 2009-04-27 at 10:39 +0200, Ingo Molnar wrote:
> > >> * Dave Airlie <[email protected]> wrote:
> > >>
> > >> > Hi guys,
> > >> >
> > >> > I just noticed CONFIG_DRM_I915_KMS is enabled for x86-64.
> > >> >
> > >> > This should never be the case, as anyone who built defconfig
> > >> > kernels before, will now get KMS enabled when really they need
> > >> > to have done userspace upgrades.
> > >>
> > >> I've yet to see such a bugreport.
> > >
> > > Whenever I accidentally enable KMS I get a dead X (happens way
> > > more often that I'd like to), I blame this on the ubuntu Xorg
> > > packages, but can't be arsed to fix it myself -- hopefully the
> > > kinky koala will fix stuff, but who knows.
> >
> > Well you can't really blame anyone else for it, since you have to
> > put the code upstream
> > in the kernel before you can release drivers that use it for
> > distros to package.
> >
> > So it would be impossible for any distro to have shipped kms
> > drivers in a useful fashion before KMS is actually in the kernel.
>
> Can't the driver detect KMS and use it when present? In that case they
> could just ship a KMS capable driver that works either way.
>
> Anyway, I'm sure it'll all sort itself out.
Yeah Jaunty has such drivers, but Intrepid released with 2.4.x
xf86-video-intel drivers I think, which doesn't have autodetection.
--
Jesse Barnes, Intel Open Source Technology Center
On Tue, 28 Apr 2009, [email protected] wrote:
>
> as a end-user creating my own configs, I use the defaults as a guide to
> understand when something moves from "we think it's a good idea" to "things
> really need this"
I'm not talking about the defaults in the Kconfig files themselves, I'm
talking about the millions of "*_defconfig" files that have tons of random
default values.
> there's a _lot_ of stuff that goes in that is useful only is some situations,
> and the help text frequently doesn't help understanding what's really needed
> vs what the author of that feature _thinks_ is really needed (containers are a
> perfect example, they aren't needed in 99% of current systems, but it's
> actually _hard_ to really disable them completely)
Oh, I agree that the help text is not sufficient, and having new Kconfig
options have sane default values is good.
> you mention starting from a distro config, but most distro configs have a
> _huge_ number of things enabled that aren't needed for any particular box.
I think starting from the distro config and then turning off all modules
("sed s/=m/=n/") is a good way to start off. Then enable just the modules
that are actually loaded.
Of course, you then need to be aware of the things you may want even if
they're not connected right now (eg things like FAT support). And
sometimes it's hard to map "module name" -> "config options that need to
be enabled".
So yes, it would be good to automate it:
> If a tool was available to detect the hardware and create a config tailored
> for the box, this use for a default config would go away
Yeah, I've wished for that.
Although I personally don't find that the actual hardware to be the
biggest issue (since there are usually just a few options for that, and
they are mostly not confusing). Instead, it's the issues about knowing
which software components (netfilter, filesystems, auditing, POSIX ACL's)
that you really want.
It tends to be easy to just enable them all, but if you want a nice
efficient build, that's very much against the point.
So having some kind of (probably inevitably fairly complex) script that
you could run to get a config would be good. The problem is that the
script would need to be distributed with the kernel, yet it would often
also have some nasty distro issues.
Linus
* Linus Torvalds <[email protected]> wrote:
> So yes, it would be good to automate it:
>
> > If a tool was available to detect the hardware and create a
> > config tailored for the box, this use for a default config would
> > go away
>
> Yeah, I've wished for that.
Steve (Cc:-ed) submitted such a script last year IIRC. It wasnt
particularly complex.
Ingo
On Tue, 28 Apr 2009, Linus Torvalds wrote:
> On Tue, 28 Apr 2009, [email protected] wrote:
>>
>> as a end-user creating my own configs, I use the defaults as a guide to
>> understand when something moves from "we think it's a good idea" to "things
>> really need this"
>
> I'm not talking about the defaults in the Kconfig files themselves, I'm
> talking about the millions of "*_defconfig" files that have tons of random
> default values.
Ok, I misunderstood.
>> If a tool was available to detect the hardware and create a config tailored
>> for the box, this use for a default config would go away
>
> Yeah, I've wished for that.
>
> Although I personally don't find that the actual hardware to be the
> biggest issue (since there are usually just a few options for that, and
> they are mostly not confusing). Instead, it's the issues about knowing
> which software components (netfilter, filesystems, auditing, POSIX ACL's)
> that you really want.
yes and no, getting a config that will boot on your system can sometimes
be 'interesting' (mapping hardware -> config option for example), but
should be able to be automated.
the other items that you mention (netfilter, etc) are actually the easier
ones to deal with (you know what you want), and also the place where it's
impossible to detect what's wanted.
> It tends to be easy to just enable them all, but if you want a nice
> efficient build, that's very much against the point.
>
> So having some kind of (probably inevitably fairly complex) script that
> you could run to get a config would be good. The problem is that the
> script would need to be distributed with the kernel, yet it would often
> also have some nasty distro issues.
I've seen people talk about creating such tools, but the responses that
I've seen have tended to discourage them.
David Lang
On Tue, 28 Apr 2009, Ingo Molnar wrote:
>
> * Linus Torvalds <[email protected]> wrote:
>
> > So yes, it would be good to automate it:
> >
> > > If a tool was available to detect the hardware and create a
> > > config tailored for the box, this use for a default config would
> > > go away
> >
> > Yeah, I've wished for that.
>
> Steve (Cc:-ed) submitted such a script last year IIRC. It wasnt
> particularly complex.
I've submitted the script a few times to LKML but it is not exactly what
people want, but is quite useful in the mean time.
What people want is a script that will analyze their system devices and
enable all the configs that will support them.
My script requires that you have booted the kernel (or similar kernel with
the same config options and modules). It then runs lsmod, and searches for
the options that enable those modules. It then reads the current .config
file and prints out a new config that disables all module configs that are
not used to enable the modules found with lsmod.
Here's the code (perl script):
http://rostedt.homelinux.com/code/streamline_config.pl
The instructions on how to use it are at the top of the file.
This script has brought down my full kernel compile times with distcc from
50 minutes to under 10.
-- Steve
On Tue, 28 Apr 2009, [email protected] wrote:
>
> the other items that you mention (netfilter, etc) are actually the easier ones
> to deal with (you know what you want), and also the place where it's
> impossible to detect what's wanted.
Very wrong.
Especially about the "you know what you want".
Quite frankly, those choices can be hard even for kernel developers, never
mind normal users. Have you looked at the _hundreds_ of options for
various iptables filtering? Do you know which ones you need?
[ Ok, so now you can say "give me the non-complex set" and it will pick
the normal ones. It will still ask you about others. I had to ask for
that option, and when I did, even the main netfilter developers had to
say "ok, I'll have to check".
The point being - normal mortals have almost no way of knowing which sw
features are good, and which are bad. And yes, some of them are really
bad. They not only increase compile time, some of them make for horrible
performance. You may want to enable some options that increase debug
coverage, but can you tell which of them impact kernel performance by a
factor of ten on some loads? ]
And that's where starting with a "suggested config" can help. And some of
the suggestions really are distro-specific, because sometimes different
distributions depend on different features.
> > So having some kind of (probably inevitably fairly complex) script that
> > you could run to get a config would be good. The problem is that the
> > script would need to be distributed with the kernel, yet it would often
> > also have some nasty distro issues.
>
> I've seen people talk about creating such tools, but the responses that I've
> seen have tended to discourage them.
I suspect that they'd generally end up handling the easy cases, and seldom
anything more. At which point they're not all that useful.
Linus
* Steven Rostedt <[email protected]> wrote:
> On Tue, 28 Apr 2009, Ingo Molnar wrote:
>
> >
> > * Linus Torvalds <[email protected]> wrote:
> >
> > > So yes, it would be good to automate it:
> > >
> > > > If a tool was available to detect the hardware and create a
> > > > config tailored for the box, this use for a default config would
> > > > go away
> > >
> > > Yeah, I've wished for that.
> >
> > Steve (Cc:-ed) submitted such a script last year IIRC. It wasnt
> > particularly complex.
>
> I've submitted the script a few times to LKML but it is not
> exactly what people want, but is quite useful in the mean time.
>
> What people want is a script that will analyze their system
> devices and enable all the configs that will support them.
>
> My script requires that you have booted the kernel (or similar
> kernel with the same config options and modules). It then runs
> lsmod, and searches for the options that enable those modules. It
> then reads the current .config file and prints out a new config
> that disables all module configs that are not used to enable the
> modules found with lsmod.
>
> Here's the code (perl script):
>
> http://rostedt.homelinux.com/code/streamline_config.pl
>
> The instructions on how to use it are at the top of the file.
>
> This script has brought down my full kernel compile times with
> distcc from 50 minutes to under 10.
Looks rather useful IMHO.
I use the following magic incantation in cfs-debug-info.sh to get to
the distro config automatically:
KREL=`uname -r | sed 's/smp$//g'`
( cat "`rpm -ql kernel-$KREL 2>/dev/null | grep /boot/config`"
cat "`rpm -ql kernel-smp-$KREL 2>/dev/null | grep /boot/config`"
cat "`dpkg -L linux-image-$KREL 2>/dev/null | grep /boot/config`"
cat /boot/config-$KREL 2>/dev/null
)
Works on most .rpm and .deb based distros. (If /proc/config.gz is
present that could be added too.)
So if this was added as a 'make builtinconfig' kind of shortcut,
with no extra steps needed (and if the script bailed out if it
cannot find the currently booted .config) - that would be a rather
useful (and easy) way to start kernel development on a new box.
Useful to newbies and oldbies alike IMHO.
Ingo
On Tue, 28 Apr 2009, Ingo Molnar wrote:
> >
> > My script requires that you have booted the kernel (or similar
> > kernel with the same config options and modules). It then runs
> > lsmod, and searches for the options that enable those modules. It
> > then reads the current .config file and prints out a new config
> > that disables all module configs that are not used to enable the
> > modules found with lsmod.
> >
> > Here's the code (perl script):
> >
> > http://rostedt.homelinux.com/code/streamline_config.pl
> >
> > The instructions on how to use it are at the top of the file.
> >
> > This script has brought down my full kernel compile times with
> > distcc from 50 minutes to under 10.
>
> Looks rather useful IMHO.
There's one little bug. It does not catch configs that are modules that
depend on other configs as modules (but do not have modules mapped).
I can fix this by also scanning the Kconfig* files, and include any
"depends on" as well.
>
> I use the following magic incantation in cfs-debug-info.sh to get to
> the distro config automatically:
>
> KREL=`uname -r | sed 's/smp$//g'`
> ( cat "`rpm -ql kernel-$KREL 2>/dev/null | grep /boot/config`"
> cat "`rpm -ql kernel-smp-$KREL 2>/dev/null | grep /boot/config`"
> cat "`dpkg -L linux-image-$KREL 2>/dev/null | grep /boot/config`"
> cat /boot/config-$KREL 2>/dev/null
> )
>
> Works on most .rpm and .deb based distros. (If /proc/config.gz is
> present that could be added too.)
>
> So if this was added as a 'make builtinconfig' kind of shortcut,
> with no extra steps needed (and if the script bailed out if it
> cannot find the currently booted .config) - that would be a rather
> useful (and easy) way to start kernel development on a new box.
>
> Useful to newbies and oldbies alike IMHO.
Yes, it would be nice to automate this.
-- Steve
On Tue, 28 Apr 2009 10:50:14 -0700 (PDT)
Linus Torvalds <[email protected]> wrote:
>
>
> On Tue, 28 Apr 2009, [email protected] wrote:
> > I've seen people talk about creating such tools, but the responses
> > that I've seen have tended to discourage them.
>
> I suspect that they'd generally end up handling the easy cases, and
> seldom anything more. At which point they're not all that useful.
>
> Linus
perhaps there needs to be an infrastructure where each
kconfig-entry-causer can also provide userlevel code to help with that
entry?
i could imagine a kconfig knob to specify an optional
per-kconfig-userspace-helperscript which calculates a new "suggested
value" at configure time.
this "suggested value" is displayed next to the default value
or is then already incorporated in the default value.
each maintainer of each kconfig entry
a) decides if it is possible to supply such a script
b) if it would be useful
c) suplies and maintains his (focused on only one kconfig entry) script
c) if the script is 100% fool-proof he can say so in the description of
the kconfig-entry or just skip the user or notify the user of the
result.
d) maybe dosn't provide an userspace helper
this spreads the burden of the complex detection-code and hopefully
eases configuration for everyone where possible.
what do others think?
sincerely,
Florian
On Tue, 28 Apr 2009, Florian Mickler wrote:
> On Tue, 28 Apr 2009 10:50:14 -0700 (PDT)
> Linus Torvalds <[email protected]> wrote:
>
>>
>>
>> On Tue, 28 Apr 2009, [email protected] wrote:
>
>>> I've seen people talk about creating such tools, but the responses
>>> that I've seen have tended to discourage them.
>>
>> I suspect that they'd generally end up handling the easy cases, and
>> seldom anything more. At which point they're not all that useful.
>>
>> Linus
>
> perhaps there needs to be an infrastructure where each
> kconfig-entry-causer can also provide userlevel code to help with that
> entry?
>
> i could imagine a kconfig knob to specify an optional
> per-kconfig-userspace-helperscript which calculates a new "suggested
> value" at configure time.
> this "suggested value" is displayed next to the default value
> or is then already incorporated in the default value.
what is the difference between the default value and this suggested value?
> each maintainer of each kconfig entry
> a) decides if it is possible to supply such a script
> b) if it would be useful
> c) suplies and maintains his (focused on only one kconfig entry) script
please no!!! we don't want to have to run 2000 different scripts to get
the settings.
one script.
David Lang
> c) if the script is 100% fool-proof he can say so in the description of
> the kconfig-entry or just skip the user or notify the user of the
> result.
> d) maybe dosn't provide an userspace helper
>
> this spreads the burden of the complex detection-code and hopefully
> eases configuration for everyone where possible.
>
> what do others think?
>
>
> sincerely,
> Florian
>
On Tue, 28 Apr 2009 14:50:08 -0700 (PDT)
[email protected] wrote:
> On Tue, 28 Apr 2009, Florian Mickler wrote:
>
> > perhaps there needs to be an infrastructure where each
> > kconfig-entry-causer can also provide userlevel code to help with
> > that entry?
> >
> > i could imagine a kconfig knob to specify an optional
> > per-kconfig-userspace-helperscript which calculates a new "suggested
> > value" at configure time.
> > this "suggested value" is displayed next to the default value
> > or is then already incorporated in the default value.
>
> what is the difference between the default value and this suggested
> value?
well... for example:
----snip----
config MY_NEW_DRIVER
bool "mynewDriver"
default n
helper obey
help
this is my new shiny driver which speeds up the system by factor of
ten if the hardware is available. it the hardware is not available
this reduces performance by the factor of 5.
if unshure say 42.
----snap----
and the helper line causes the Kconfig script to execute
"some_path/userspacehelper.sh MY_NEW_DRIVER"
with "obey", the return value would override the default value
with "definitive_no", it would overide the default value with "no" if
the script returned "no",
with "definitive_yes", it would override the default value with "yes"
if the script returned "yes"
there could also be an msg displayed:
"userspace config helper says: the machine seems to have the hardware
but it has to be enabled in the bios!"
maybe. maybe not.
perhaps the "obey" "definitive_yes" "definitive_no" has to come from
the helperscript too... dunno....
>
> > each maintainer of each kconfig entry
> > a) decides if it is possible to supply such a script
> > b) if it would be useful
> > c) suplies and maintains his (focused on only one kconfig entry)
> > script
>
> please no!!! we don't want to have to run 2000 different scripts to
> get the settings.
>
> one script.
>
> David Lang
hmm... alright, but that's not my main point here. the point is to
have some infrastructure in the kconfig script for
configure-time-hardware-detection.
the rest is more an question of how to organize the work. however a
modularized approach has more appeal in my eyes. but this was only
me thinking out loud...
there could be one script which facilitates the results of steve's
allmod-cut-down script.
i could also imagine having only one helperscript which knows it all.
or there could be one which knows which script to call for what
config-symbol.
there could be the default-one, bundled with the kernel and
third-party-scripts which may or may not fall back to the default one,
but can override it.
this would also enable some script to first generate some "hardware-id"
and query the internet for known bad and known good config-facts for
this platform and filter the in tree detection logic. (like when that
machine has support for two equivalent services, but one is to be
preferred on that platform because of a dumb biosbug or because of
some social contract one has with the tasmanian devil)
there are many options. it just needs to be done(tm)
i'm gonna try to experiment a bit with smth like this, but maybe it
turns out that the idea is not so good after all. who knows...
>
> > c) if the script is 100% fool-proof he can say so in the
> > description of the kconfig-entry or just skip the user or notify
> > the user of the result.
> > d) maybe dosn't provide an userspace helper
> >
> > this spreads the burden of the complex detection-code and hopefully
> > eases configuration for everyone where possible.
> >
> > what do others think?
> >
> >
> > sincerely,
> > Florian
> >
On Wed, 29 Apr 2009, Florian Mickler wrote:
> On Tue, 28 Apr 2009 14:50:08 -0700 (PDT)
> [email protected] wrote:
>
>> On Tue, 28 Apr 2009, Florian Mickler wrote:
>>
>>> perhaps there needs to be an infrastructure where each
>>> kconfig-entry-causer can also provide userlevel code to help with
>>> that entry?
>>>
>>> i could imagine a kconfig knob to specify an optional
>>> per-kconfig-userspace-helperscript which calculates a new "suggested
>>> value" at configure time.
>>> this "suggested value" is displayed next to the default value
>>> or is then already incorporated in the default value.
>>
>> what is the difference between the default value and this suggested
>> value?
>
> well... for example:
>
> ----snip----
> config MY_NEW_DRIVER
> bool "mynewDriver"
> default n
> helper obey
> help
> this is my new shiny driver which speeds up the system by factor of
> ten if the hardware is available. it the hardware is not available
> this reduces performance by the factor of 5.
> if unshure say 42.
> ----snap----
>
> and the helper line causes the Kconfig script to execute
> "some_path/userspacehelper.sh MY_NEW_DRIVER"
>
> with "obey", the return value would override the default value
>
> with "definitive_no", it would overide the default value with "no" if
> the script returned "no",
>
> with "definitive_yes", it would override the default value with "yes"
> if the script returned "yes"
>
> there could also be an msg displayed:
> "userspace config helper says: the machine seems to have the hardware
> but it has to be enabled in the bios!"
>
> maybe. maybe not.
>
> perhaps the "obey" "definitive_yes" "definitive_no" has to come from
> the helperscript too... dunno....
>
>
>>
>>> each maintainer of each kconfig entry
>>> a) decides if it is possible to supply such a script
>>> b) if it would be useful
>>> c) suplies and maintains his (focused on only one kconfig entry)
>>> script
>>
>> please no!!! we don't want to have to run 2000 different scripts to
>> get the settings.
>>
>> one script.
>>
>> David Lang
>
> hmm... alright, but that's not my main point here. the point is to
> have some infrastructure in the kconfig script for
> configure-time-hardware-detection.
_many_ people compile kernels on different hardware than they will be
running it on.
keep the autodetect script seperate from the kernel compile/configure
in fact, if possible the autodetect script should not require the kernel
source (to make it easier to do the autodetect on many different systems)
David Lang
> the rest is more an question of how to organize the work. however a
> modularized approach has more appeal in my eyes. but this was only
> me thinking out loud...
>
> there could be one script which facilitates the results of steve's
> allmod-cut-down script.
>
> i could also imagine having only one helperscript which knows it all.
> or there could be one which knows which script to call for what
> config-symbol.
>
> there could be the default-one, bundled with the kernel and
> third-party-scripts which may or may not fall back to the default one,
> but can override it.
>
> this would also enable some script to first generate some "hardware-id"
> and query the internet for known bad and known good config-facts for
> this platform and filter the in tree detection logic. (like when that
> machine has support for two equivalent services, but one is to be
> preferred on that platform because of a dumb biosbug or because of
> some social contract one has with the tasmanian devil)
>
> there are many options. it just needs to be done(tm)
>
> i'm gonna try to experiment a bit with smth like this, but maybe it
> turns out that the idea is not so good after all. who knows...
>
>>
>>> c) if the script is 100% fool-proof he can say so in the
>>> description of the kconfig-entry or just skip the user or notify
>>> the user of the result.
>>> d) maybe dosn't provide an userspace helper
>>>
>>> this spreads the burden of the complex detection-code and hopefully
>>> eases configuration for everyone where possible.
>>>
>>> what do others think?
>>>
>>>
>>> sincerely,
>>> Florian
>>>
>
On Tue, Apr 28, 2009 at 5:32 PM, Peter Zijlstra <[email protected]> wrote:
> On Tue, 2009-04-28 at 11:54 +1000, Dave Airlie wrote:
>> On Tue, Apr 28, 2009 at 1:40 AM, Peter Zijlstra <[email protected]> wrote:
>> > On Mon, 2009-04-27 at 10:39 +0200, Ingo Molnar wrote:
>> >> * Dave Airlie <[email protected]> wrote:
>> >>
>> >> > Hi guys,
>> >> >
>> >> > I just noticed CONFIG_DRM_I915_KMS is enabled for x86-64.
>> >> >
>> >> > This should never be the case, as anyone who built defconfig
>> >> > kernels before, will now get KMS enabled when really they need to
>> >> > have done userspace upgrades.
>> >>
>> >> I've yet to see such a bugreport.
>> >
>> > Whenever I accidentally enable KMS I get a dead X (happens way more
>> > often that I'd like to), I blame this on the ubuntu Xorg packages, but
>> > can't be arsed to fix it myself -- hopefully the kinky koala will fix
>> > stuff, but who knows.
>>
>> Well you can't really blame anyone else for it, since you have to put
>> the code upstream
>> in the kernel before you can release drivers that use it for distros to package.
>>
>> So it would be impossible for any distro to have shipped kms drivers in a useful
>> fashion before KMS is actually in the kernel.
>
> Can't the driver detect KMS and use it when present? In that case they
> could just ship a KMS capable driver that works either way.
>
Again it can't tell the future. The kernel can't know what userspace
driver is installed
or what driver the X server is going to run on it. So new drivers can
of course deal with both cases
as the userspace driver is kms aware, but a non-kms aware userspace cannot know
about KMS without time travel.
Once distros ship the kms aware userspaces then it should all work fine.
Dave.
On Mon, 27 Apr 2009 18:56:27 +1000 Dave Airlie <[email protected]> wrote:
> > KMS is the sane design for graphics and i'd go as far as to consider
> > user-space mode setting an outright _bug_. It look a long time to
> > fix but now lets look forward and fix all the bugs in KMS, ASAP ...
>
> Its mainly for things like Andrews Vaio, people will not expect a new kernel
> to take out any current userspace, its a pain, but we assume distros + people
> who compile their own kernels will know what userspace exists on their
> machines and other will get the least surprise.
My Vaio thanks you.
What is the expected user-visible failure mode when someone enables KMS
on naive userspace? iow, how can bug report screeners recognise when this has
happened?
On Wed, Apr 29, 2009 at 3:36 PM, Andrew Morton
<[email protected]> wrote:
> On Mon, 27 Apr 2009 18:56:27 +1000 Dave Airlie <[email protected]> wrote:
>
>> > KMS is the sane design for graphics and i'd go as far as to consider
>> > user-space mode setting an outright _bug_. It look a long time to
>> > fix but now lets look forward and fix all the bugs in KMS, ASAP ...
>>
>> Its mainly for things like Andrews Vaio, people will not expect a new kernel
>> to take out any current userspace, its a pain, but we assume distros + people
>> who compile their own kernels will know what userspace exists on their
>> machines and other will get the least surprise.
>
> My Vaio thanks you.
>
> What is the expected user-visible failure mode when someone enables KMS
> on naive userspace? ?iow, how can bug report screeners recognise when this has
> happened?
>
>
Generally X doesn't start, or X starts but dies soon after, so its
fairly easy to nail down from
xorg log file and dmesg.
Dave.
Florian Mickler wrote:
> On Tue, 28 Apr 2009 10:50:14 -0700 (PDT)
> Linus Torvalds <[email protected]> wrote:
>
>>
>> On Tue, 28 Apr 2009, [email protected] wrote:
>
>>> I've seen people talk about creating such tools, but the responses
>>> that I've seen have tended to discourage them.
>> I suspect that they'd generally end up handling the easy cases, and
>> seldom anything more. At which point they're not all that useful.
>>
>> Linus
>
> perhaps there needs to be an infrastructure where each
> kconfig-entry-causer can also provide userlevel code to help with that
> entry?
>
> i could imagine a kconfig knob to specify an optional
> per-kconfig-userspace-helperscript which calculates a new "suggested
> value" at configure time.
> this "suggested value" is displayed next to the default value
> or is then already incorporated in the default value.
>
> each maintainer of each kconfig entry
> a) decides if it is possible to supply such a script
> b) if it would be useful
> c) suplies and maintains his (focused on only one kconfig entry) script
> c) if the script is 100% fool-proof he can say so in the description of
> the kconfig-entry or just skip the user or notify the user of the
> result.
> d) maybe dosn't provide an userspace helper
>
> this spreads the burden of the complex detection-code and hopefully
> eases configuration for everyone where possible.
>
> what do others think?
Not feasible! Look at the default values or at the help text of options:
you see a lot of old and obsolete text.
Take e.g.: CONFIG_SMP, the intel AGP/DRI, or in general: help texts describe
usually only the first hardwares supported.
I think such scripts could not do better: soon will be obsolete.
It is also not difficult to do a central script.
I regularly build a map from modules, mosts buses, etc to the kernel config
(see lkddb.list in http://cateee.net/sources/lkddb ). With explicit
coding policy and few patches in kernel it would be easier to generate, but...
the problem is in Kconfig: actual interface is ugly:
it is difficult to know how to add support for an hardware, or to
remove a driver (because of linear dependencies and need to fullfil
the dependencies before to enable/disable drivers), and dependencies are
often not obvious.
Take a default kernel from your distribution and try to remove most of
non-needed hardware, using existing interfaces (ok, the Linus' sed method
simplify the problem, but try to do manually with menuconfig.
After we replace the build system we could try to develop a right
"autoconfiguration", which is IMHO a trivial task.
But the new build system need to solve dependencies (like modern
package managers). Actual system checks only dependencies, but user
must know and set it before to configure a specific item.
But creating a new configuration system, with dependency solver, is very
complex: the kernel has an interesting third state: "m". So we should handle
3 cases: n/m/y, and some policies:
- prefer m / prefer y
- default values
- on usefull (e.g. filesystems) "non hardware": n / m / y
(but not on virtualization, debug)
- ...
So the old problem: automation and complexity: the solver must do the right thing,
but probably there is no "right thing" for everybody (or for most people), so we
cannot automatize it.
ciao
cate