Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN_FIRMWARE option

[Marcel Holtmann]

Hi Michael,

> > don't give me that crap. Nobody plans to break everything just right
> > now and leave people hanging in between. We will do a smooth
> > transition. Your users won't even notice it.
>
> Right. I will forward any complain mail to you then.
> This is not the first time we (need to) change the firmware ABI, so I
> pretty much know what I'm talking about.
>
> I still didn't see a single valid reason in the whole thread that  
> explains
> why we suddenly have to forbid the use of the "/" character. (and  
> that's
> really what my problem only is about)

the reason is pretty simple; the a kernel driver should not do any  
kind of policy, namespace or whatever you wanna call it. This should  
be done in userspace.

> > And we change the API/ABI all the time. Get used to it.
>
> Right. And endusers are really scared by it.
> Other operating systems out there can live without ABI breakage for  
> 10 years.

And some operating system really suffer from this ABI guarantee. I am  
not getting into this since it has been discussed so many times and  
the kernel source contains full documentation why we are not doing it.

> Breakage example? I have a server running Ubuntu Dapper. I'm running  
> a 2.6.23 kernel on
> it and it complains that several features used by the dapper udev  
> will go away in
> a future kernel release. So if I want to update the kernel (security  
> update or
> for whatever reason) I need to upgrade the whole distribution,  
> basically.
> That is OK and I will do this. But this just shows that we really  
> must try hard
> to avoid breaking the udev ABI.
> And I don't see this happening here.

We actually do and we the future remove document and the requirements  
document within the kernel source this is fully documented all of the  
time.

However you have to understand that at some point we have to make sure  
that kernel and userspace are recent. But again, this will be all  
documented and if a distro than decides to bluntly ignore it, then go  
ahead an blame the distro. The kernel depends on the "plumbing" and  
vise versa.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/