1 |
On Wed, 3 Jul 2013 15:06:07 +0200 |
2 |
Tom Wijsman <TomWij@g.o> wrote: |
3 |
|
4 |
> On Tue, 2 Jul 2013 21:16:07 +0300 |
5 |
> Sergei Trofimovich <slyfox@g.o> wrote: |
6 |
> |
7 |
> > udev's case: |
8 |
> > It's _not_ the kernel which upgrade breaks user's system. Why do you |
9 |
> > try to "fix" it? If you want to save user's box - make check at |
10 |
> > pre-install time. Otherwise it will break. |
11 |
> |
12 |
> Won't work for stage3's case, where this check won't run. |
13 |
|
14 |
Non-issue. |
15 |
- stage3 does not work out of the box. you can't boot or run it |
16 |
- stage3 does not work at all in containers w/o devtmpfs kernel. |
17 |
no matter what you try to force on newly built kernel. |
18 |
|
19 |
Let's consider real-world examples: |
20 |
|
21 |
My friend at cloud hosting company decided to try gentoo on |
22 |
a xen hypervisor box (3.0.6 host w/o devtmpfs). unpacked old |
23 |
stage3, which worked; merged new stuff there and rebooted. |
24 |
No kernel change, old xen 3.0.6. Guess what happened when he |
25 |
upgraded udev afterwards. |
26 |
|
27 |
Another my friend unpacked stage3 on his handheld with android kernel. |
28 |
2.6.3x-something w/o accept4() syscall. Original stage3 worked, upgrade |
29 |
broke system. |
30 |
|
31 |
> > kernel's case: |
32 |
> > CONFIG_DEVTMPFS needs 'default yes', right? One-liner to |
33 |
> > gentoo-sources. |
34 |
> |
35 |
> It's not as simple as a one-liner, because we need to respect people |
36 |
> that want to build a kernel without that; not everyone who uses |
37 |
> genpatches runs a Gentoo system, and note every other OS needs that |
38 |
> variable to enabled. |
39 |
|
40 |
'default yes' is a Kconfig option. It picks a value if user didn't pick it |
41 |
explicitely. |
42 |
|
43 |
linux/drivers/base/Kconfig: |
44 |
config DEVTMPFS |
45 |
bool "Maintain a devtmpfs filesystem to mount at /dev" |
46 |
depends on HOTPLUG |
47 |
+ default y |
48 |
|
49 |
One-liner, no? |
50 |
|
51 |
> > Why 'hide' it? It's very counterintuitive. |
52 |
> |
53 |
> What is being hidden? |
54 |
|
55 |
You plan to have it visible only when something gentoo-specific needs |
56 |
to be disabled. |
57 |
[from origina post] |
58 |
> This is why I think it would be handy to add a Gentoo section to the |
59 |
> kernel, along the lines as described by Linus. |
60 |
> |
61 |
> https://lkml.org/lkml/2012/7/13/369 |
62 |
|
63 |
AFAIU I won't allow deselecting option until you deselect gentoo-specific bit. |
64 |
|
65 |
If you plan to upstream everything, then ok, no distro-specific hacks. |
66 |
|
67 |
> > What will you do with all-those-required-to-boot-properly |
68 |
> > - root filesystem |
69 |
> > - disk controller |
70 |
> > - USB keyboard drivers |
71 |
> > ? |
72 |
> > Include them all unless CONFIG_DONT_REMOVER_OR_WONT_BOOT |
73 |
> > option? |
74 |
> |
75 |
> These don't fall under options that need to be enabled for everyone. |
76 |
> |
77 |
> From what I see on chat and forums, people often set all these fine; |
78 |
> yet they not always enable CONFIG_DEVTMPFS and similar variables. |
79 |
> |
80 |
> We deal with the absolutely necessary, not spoon feed every option. |
81 |
> |
82 |
> > I'm afraid I don't see how it's a solution. |
83 |
> > Suppose, tomorrow's udev will require CONFIG_foo, and glibc will |
84 |
> > require CONFIG_bar. How will you save user with your mechanism? |
85 |
> |
86 |
> I don't see how we don't save them; but well, I'm not entirely sure if |
87 |
> you're talking about the opening post mechanism or another one here. |
88 |
|
89 |
Yeah, the opening post one. |
90 |
Suppose, tomorrow's udev requires CONFIG_CGROUPS=y. |
91 |
What are your actions to save user's box? |
92 |
|
93 |
Issue new gentoo-sources and pray user will install/boot it |
94 |
before new udev? See my first two examples. |
95 |
|
96 |
-- |
97 |
|
98 |
Sergei |