[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200805252027.51377.mb@bu3sch.de>
Date: Sun, 25 May 2008 20:27:50 +0200
From: Michael Buesch <mb@...sch.de>
To: Marcel Holtmann <marcel@...tmann.org>
Cc: Johannes Berg <johannes@...solutions.net>,
David Woodhouse <dwmw2@...radead.org>,
Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org,
aoliva@...hat.com, alan@...rguk.ukuu.org.uk,
Abhay Salunke <Abhay_Salunke@...l.com>, kay.sievers@...y.org,
Takashi Iwai <tiwai@...e.de>
Subject: Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN_FIRMWARE option
On Sunday 25 May 2008 20:15:13 Marcel Holtmann wrote:
> 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)
> 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.
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.
--
Greetings Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists