hal Digest, Vol 4, Issue 47

Andrew Luecke worse.off.then.shrek at gmail.com
Thu Jul 1 23:22:50 PDT 2004 

The problem is far from solved.. Alpha 1 basically relied on source to
do it. I currently have one theory on what might make it possible to
get this working (like change the #includes from static to dynamic,
etc, make it cover everything, maybe make the header info more
dynamic), but thats probably the best idea I have at the moment..
otherwise it might not be possible to do the way I really want it. So
my current theory is do stuff like:

#ifdef(KERNEL_PREEMPT)
//bleh
#endif

change to: 

if (kernel_option_enabled("KERNEL_PREEMPT") {

Or something similiar I guess.. Not sure if it can work, but
theoretically, it should.

My only other theory is taking advantage of GCC 3.4 and its
object/precompiled header system.. With that the source code might be
able to be compiled into an object file, on the users system they
might precompile the header for it, and then GCC just ends up linking
the 2 during distribution, which will only take a second or 2, and
eliminate the compiling stage. But I highly doubt this way will work,
simply because I severely doubt that GCC 3.4 can completely precompile
it independantly  (in fact, I'm not even going to pretend like there
is any remote chance that the second idea will work, but that would be
the easiest, and best way), but the initial choice theoretically works
( I dont see why it shouldn't).

Would be slower because there would be many more if's to go through,
might have to change some structs slightly too, but do you think
something like that could work??

OR do you have any ideas?? 

Cause the potential of this project seems to be dropping quickly :(


Auzy 

On Wed Jun 30 12:00:12 PDT 2004, hal-request at freedesktop.org
<hal-request at freedesktop.org> wrote:
> 
> Send hal mailing list submissions to
>         hal at freedesktop.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://freedesktop.org/mailman/listinfo/hal
> or, via email, send a message with subject or body 'help' to
>         hal-request at freedesktop.org
> 
> You can reach the person managing the list at
>         hal-owner at freedesktop.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hal digest..."
> 
> Today's Topics:
> 
>    1. hal and battery status (Nathaniel McCallum)
>    2. Clarification of loadable drivers (Jono Bacon)
>    3. Re: Clarification of loadable drivers (Sean Middleditch)
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 30 Jun 2004 10:21:46 -0400
> From: Nathaniel McCallum <npmccallum at gentoo.org>
> Subject: hal and battery status
> To: hal at freedesktop.org
> Message-ID: <1088605306.29052.8.camel at aquinas.natemccallum.com>
> Content-Type: text/plain
> 
> Is hal going to eventually have powermanagement devices? (batteries,
> etc)
> 
> Nathaniel
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 30 Jun 2004 17:06:18 +0100
> From: Jono Bacon <jono at jonobacon.org>
> Subject: Clarification of loadable drivers
> To: hal at freedesktop.org
> Message-ID: <40E2E4FA.10509 at jonobacon.org>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> 
> Hi all,
> 
> I know you are probably all at GUADEC, but I wanted to pose a question
> to the list.
> 
> With regards to the Driver On Demand project that has been discussed
> recently and the network centric .fdi file respository, I wanted to see
> how reasonable it was in theory to load a driver on demand. A few questions:
> 
>   - Am I right in thinking that someone could take a stock 2.6.x kernel
> and compile a module, then take that module and put it on another system
> with a 2.6.x kernel and it would work?
> 
>   - Would a module for 2.6.x work with any other minor revision of 2.6.x?
> 
>   - Do different compiled kernels for different distros (such as the
> RedHat kernel, Debian kernel etc) allow you to take modules and use them
> on any kernel of the same version?
> 
> It strikes me that if we are going to face issues allowing modules from
> different version of 2.6.x to work with each other, this is going to be
> a major stumbling block. I would have thought that 2.6 would preserve
> ABI compatibility across the different minor releases, but I may be
> wrong, hence the question. :P
> 
> If we can intermingle different 2.6.x modules across minor releases, we
> then face the challenge of modules compiled for different distro cases.
> 
> I just want to clarify how much of this is possible at the moment. I
> know Andrew has written a working system with Driver On Demand, but I
> want to clarify what the situation is regarding compatability with
> kernel modules so I can better justify where we are at.
> 
> Cheers,
> 
>         Jono
> 
> --
> Jono Bacon - http://www.jonobacon.org/
> Writer / Journalist / Consultant / Developer
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 30 Jun 2004 13:01:12 -0400
> From: Sean Middleditch <elanthis at awesomeplay.com>
> Subject: Re: Clarification of loadable drivers
> To: hal at freedesktop.org
> Message-ID:
>         <1088614871.1619.10.camel at support02.civic.twp.ypsilanti.mi.us>
> Content-Type: text/plain
> 
> On Wed, 2004-06-30 at 12:06, Jono Bacon wrote:
> > Hi all,
> 
> >   - Am I right in thinking that someone could take a stock 2.6.x kernel
> > and compile a module, then take that module and put it on another system
> > with a 2.6.x kernel and it would work?
> 
> >   - Would a module for 2.6.x work with any other minor revision of 2.6.x?
> >
> >   - Do different compiled kernels for different distros (such as the
> > RedHat kernel, Debian kernel etc) allow you to take modules and use them
> > on any kernel of the same version?
> >
> 
> Only if it's the exact same kernel with the exact same patches with the
> exact same options compiled using the exact same compiler.  The kernel
> folks don't give a damn about usability, they seem to think users are
> perfectly alright with having to upgrade, repatch, rebuild, and install
> a new kernel every time they need a new driver for a device that didn't
> come with the kernel they're currently running.  ABI/API are not
> maintained even within the same point release, much less the same kernel
> series.  Even when compiling from source there is still no guarantee
> that you can take a completely Open Source driver and compile it for a
> given kernel.
> 
> > It strikes me that if we are going to face issues allowing modules from
> > different version of 2.6.x to work with each other, this is going to be
> > a major stumbling block. I would have thought that 2.6 would preserve
> > ABI compatibility across the different minor releases, but I may be
> > wrong, hence the question. :P
> 
> They don't even maintain API compatibility.  The kernel developers in
> general don't give a damn about real users.
> >
> > If we can intermingle different 2.6.x modules across minor releases, we
> > then face the challenge of modules compiled for different distro cases.
> 
> It is completely infeasible to distribute binary modules.  You will have
> to distribute source, require users to have all necessary development
> tools and support headers and such, and carry several copies of each
> driver source depending on which kernel API version they are compatible
> with.
> --
> Sean Middleditch <elanthis at awesomeplay.com>
> AwesomePlay Productions, Inc.
> 
> ------------------------------
> 
> _______________________________________________
> hal mailing list
> hal at freedesktop.org
> http://freedesktop.org/mailman/listinfo/hal
> 
> End of hal Digest, Vol 4, Issue 47
> **********************************
> 


-- 
Auzy
http://driverondemand.sourceforge.net

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal

More information about the Hal mailing list