From: John Cavan <johnc@damncats.org>
To: Jeff Hartmann <jhartmann@valinux.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: 4.1.0 DRM (was Re: Linux 2.4.6-ac3)
Date: Mon, 16 Jul 2001 15:49:41 -0400 [thread overview]
Message-ID: <3B534555.345015EC@damncats.org> (raw)
In-Reply-To: <E15M6jC-0005PK-00@the-village.bc.nu> <3B532BB7.1050300@valinux.com> <3B533578.A4B6C25F@damncats.org> <3B53413A.6060501@valinux.com>
Jeff Hartmann wrote:
> > Would it not be a bit more robust to have a wrapper module that pulls in
> > the correct one on demand? In other words, for the radeon, you would
> > still have the radeon.o module, but it would determine which child
> > module to load depending on the version of X that is requesting it. Thus
> > XFree86 would not require any changes and the backwards compatibility
> > would be maintained invisibly.
> >
> > John
> >
> No, because the 2D ddx module is the one doing all the versioning. It
> doesn't tell the kernel its version number etc., but the ddx module gets
> the version from the kernel, and fails if its the wrong one. If the
> kernel was the one doing the checking, then your suggestiong would be a
> nice way of handling it.
Okay, that makes sense. However, this can still work with minimal change
to the 2D module if the next revision passes in the version information
to the kernel module. It doesn't solve the 4.0 to 4.1 transition, but it
still puts the module on a (better?) track. For the 4.0/4.1 modules,
that would have to be a compile time decision or option in the
/etc/modules.conf (options radeon version=x.y.z). Actually, having an
override in the modules.conf would be pretty handy in general.
Also, if you don't want to make changes to the 2D code, the modules.conf
scenario still makes it feasible all around.
John
next prev parent reply other threads:[~2001-07-16 19:51 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-14 17:36 Linux 2.4.6-ac3 Alan Cox
2001-07-14 20:01 ` Zilvinas Valinskas
2001-07-14 20:05 ` Alan Cox
2001-07-15 1:45 ` Gareth Hughes
2001-07-15 13:12 ` Alan Cox
2001-07-15 14:01 ` Gareth Hughes
2001-07-15 15:31 ` Alan Cox
2001-07-16 1:29 ` 4.1.0 DRM (was Re: Linux 2.4.6-ac3) Gareth Hughes
2001-07-16 1:51 ` Keith Owens
2001-07-16 2:07 ` Gareth Hughes
2001-07-16 11:23 ` John Cavan
2001-07-16 11:39 ` Alan Cox
2001-07-16 18:00 ` Jeff Hartmann
2001-07-16 18:12 ` Xavier Bestel
2001-07-16 18:32 ` Jeff Hartmann
2001-07-16 18:42 ` John Cavan
2001-07-16 19:32 ` Jeff Hartmann
2001-07-16 19:34 ` Xavier Bestel
2001-07-16 20:18 ` Jeff Hartmann
2001-07-17 2:37 ` Gareth Hughes
2001-07-17 8:31 ` Mike A. Harris
2001-07-16 19:49 ` John Cavan [this message]
2001-07-17 7:19 ` 4.1.0 DRM Mike A. Harris
2001-07-17 5:28 ` 4.1.0 DRM (was Re: Linux 2.4.6-ac3) Juan Quintela
2001-07-18 9:06 ` Gareth Hughes
2001-07-18 16:21 ` Juan Quintela
2001-07-18 13:30 ` Mike A. Harris
2001-07-17 13:19 ` Linux 2.4.6-ac3 Zdenek Kabelac
2001-07-15 1:31 ` Linux 2.4.6-ac3 - some unresolved Eyal Lebedinsky
2001-07-15 13:09 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B534555.345015EC@damncats.org \
--to=johnc@damncats.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jhartmann@valinux.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox