Date: Fri, 20 Jan 2006 17:35:51 +0100
From: Marc Koschewski <marc@osknowledge.org>
To: Michael Loftis <mloftis@wgops.com>
Cc: Marc Koschewski <marc@osknowledge.org>, linux-kernel@vger.kernel.org
Subject: Re: Development tree, PLEASE?
Message-ID: <20060120163551.GC5873@stiffy.osknowledge.org>
References: <D1A7010C56BB90C4FA73E6DD@dhcp-2-206.wgops.com> <20060120155919.GA5873@stiffy.osknowledge.org> <B6DE6A4FC14860A23FE95FF3@d216-220-25-20.dynip.modwest.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <B6DE6A4FC14860A23FE95FF3@d216-220-25-20.dynip.modwest.com>
User-Agent: Mutt/1.5.11
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2100
Lines: 46

* Michael Loftis <mloftis@wgops.com> [2006-01-20 09:07:16 -0700]:

> 
> 
> --On January 20, 2006 4:59:19 PM +0100 Marc Koschewski 
> <marc@osknowledge.org> wrote:
> 
> >For my daily work I use the -git kernels on my production machines. And I
> >didn't have probs for a long time due to stuff being tested in -mm. -mm
> >is mostly broken for me (psmouse, now reiserfs, ...) but I tend to say
> >that 2.6 is rock-stable.
> >
> >When it comes to API stability people are encouraged to stay up-to-date
> >when when developing stuff out of the kernel tree, ain't they? A more
> >convenient way would be to create a new in-kernel-tree wrapper module
> >that wraps some functions no longer available anymore and which are
> >possible to be wrapped in the meaning of all needed data is provided to
> >the 'old' method and can be easyily wrapped into the new function.
> >
> >It could a Kconfig option so that the 'wrapper module' is only activated
> >on demand. Thus, having the option to port driver directly to the new API
> >or just silenty use the 'wrapper module' to translate the call while
> >being noisy at compile time.
> >
> >You're free to write the module... ;)
> 
> I know this, but the in-kernel stuff is far less painful than when all this 
> stuff bleeds to userland.  Besides, can you imagine such a beast of a 
> module? :D  I mean yeouch, the maintenance.  And it'd encourage the sort of 
> thing we as kernel developers in general want to discourage, which is the 
> use of deprecated APIs.
> 
> Lots of things still out there depend on devfs.  So now if I want to 
> develop my kmod on recent kernels I have to be in the business of 
> maintaining a lot more userland stuff, like mkinitrd, installers, etc. that 
> have come to rely on devfs.

Moreover, as far as I remember... my devfsd -> udev transsition went as smooth
as a reboot.

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