Re: todo

Re: todo

[Jeremy Fitzhardinge]

Chris Wright wrote:
> this is the only things left on the todo i made today.
>
> Xen config
> 	PREEMPT?
>   
Remove.  Should work; any problems are bugs.

> Consistently wrap paravirt ops callsites
> 	"ugh" - mingo

Had a thought.  What if we do a kind of reverse/two-way module linkage? 
Somehow compile each pv-op implementation like a module, and then link
the appropriate one in at boot time.

Tricky parts: it would need two-way unresolved references between kernel
and module, and it would need to be able to run very early in the
kernel's life.  It would also limit us to plain old calls rather than
any inlining (though that could be done separately).

On the upside, it removes pv_ops, and it might simplify the question of
how normal module exports work, since by that time they would just be
normal kernel functions.  All the calls would be normal direct calls
rather than indirect.  And it would allow us to free the memory for the
unused pv-ops backends.

Plausible?

    J

Re: todo

[Chris Wright]

* Jeremy Fitzhardinge (jeremy@goop.org) wrote:
> Chris Wright wrote:
> > Consistently wrap paravirt ops callsites
> > 	"ugh" - mingo
> 
> Had a thought.  What if we do a kind of reverse/two-way module linkage? 
> Somehow compile each pv-op implementation like a module, and then link
> the appropriate one in at boot time.

This is very similar to something Steve was chatting with me about
this morning.  The idea he was tossing around was something a bit like
an initrd that a load_module analog could link up.  In a sense, it's
similar to the VMI ROM, with the exceptions that the ABI is just created
by the compiler from a normal mutable kernel API and it's linkage with
symbols available on both sides.

> Tricky parts: it would need two-way unresolved references between kernel
> and module, and it would need to be able to run very early in the
> kernel's life.

This is the tricky part, and where Steve and I left off.

> It would also limit us to plain old calls rather than
> any inlining (though that could be done separately).
> 
> On the upside, it removes pv_ops, and it might simplify the question of
> how normal module exports work, since by that time they would just be
> normal kernel functions.  All the calls would be normal direct calls
> rather than indirect.  And it would allow us to free the memory for the
> unused pv-ops backends.

I suspect we could free the unused backends already.  It also has one
negative side-effect, which is promoting external module code that links
with the kernel.  IOW, there's much less incentive to get code merged
if it's just a matter of linking.

thanks,
-chris

Re: todo

[Jeremy Fitzhardinge]

Chris Wright wrote:
> * Jeremy Fitzhardinge (jeremy@goop.org) wrote:
>   
>> Chris Wright wrote:
>>     
>>> Consistently wrap paravirt ops callsites
>>> 	"ugh" - mingo
>>>       
>> Had a thought.  What if we do a kind of reverse/two-way module linkage? 
>> Somehow compile each pv-op implementation like a module, and then link
>> the appropriate one in at boot time.
>>     
>
> This is very similar to something Steve was chatting with me about
> this morning.  The idea he was tossing around was something a bit like
> an initrd that a load_module analog could link up.  In a sense, it's
> similar to the VMI ROM, with the exceptions that the ABI is just created
> by the compiler from a normal mutable kernel API and it's linkage with
> symbols available on both sides.
>   

Yeah.  It would have to happen a lot earlier than initrd.  It would be
more like a multiboot kernel module or something.

>> Tricky parts: it would need two-way unresolved references between kernel
>> and module, and it would need to be able to run very early in the
>> kernel's life.
>>     
>
> This is the tricky part, and where Steve and I left off.
>   

Fortunately the linker code should be pretty easy to make
self-contained.   It shouldn't need to do memory allocations or anything
complex like that, so I think its just a matter of grovelling around and
fixing up linkages.

> I suspect we could free the unused backends already.

We could; we just need to make sure they get their own section so
they're easily separable.

>   It also has one
> negative side-effect, which is promoting external module code that links
> with the kernel.  IOW, there's much less incentive to get code merged
> if it's just a matter of linking.

It wouldn't be something we'd promote by making it easy to bind
out-of-tree code to the interface.  And it would still be a
kernel-version-specific ABI; no guarantees of stability.

    J

Re: todo

[Jeremy Fitzhardinge]

Jeremy Fitzhardinge wrote:
>>   It also has one
>> negative side-effect, which is promoting external module code that links
>> with the kernel.  IOW, there's much less incentive to get code merged
>> if it's just a matter of linking.
>>     
>
> It wouldn't be something we'd promote by making it easy to bind
> out-of-tree code to the interface.  And it would still be a
> kernel-version-specific ABI; no guarantees of stability.
BTW, my intention is definitely that all the pv-ops implementations are
linked into the kernel at build time; its just the binding references
get updated at boot time, and the unused code pages can be recycled. 
But they're all part of the same kernel image.

    J

Re: todo

[Steven Rostedt]

[added Ingo since he'd probably be interested in this]

On Fri, 2007-03-16 at 21:00 -0700, Jeremy Fitzhardinge wrote:
> Chris Wright wrote:
> > * Jeremy Fitzhardinge (jeremy@goop.org) wrote:
> >   
> >> Chris Wright wrote:
> >>     
> >>> Consistently wrap paravirt ops callsites
> >>> 	"ugh" - mingo
> >>>       
> >> Had a thought.  What if we do a kind of reverse/two-way module linkage? 
> >> Somehow compile each pv-op implementation like a module, and then link
> >> the appropriate one in at boot time.
> >>     
> >
> > This is very similar to something Steve was chatting with me about
> > this morning.  The idea he was tossing around was something a bit like
> > an initrd that a load_module analog could link up.  In a sense, it's
> > similar to the VMI ROM, with the exceptions that the ABI is just created
> > by the compiler from a normal mutable kernel API and it's linkage with
> > symbols available on both sides.
> >   
> 
> Yeah.  It would have to happen a lot earlier than initrd.  It would be
> more like a multiboot kernel module or something.

I was taking a look at kernel/module.c and arch/i386/kernel/module.c and
it looks like we can copy/modify the former and use part of the later.

> 
> >> Tricky parts: it would need two-way unresolved references between kernel
> >> and module, and it would need to be able to run very early in the
> >> kernel's life.
> >>     
> >
> > This is the tricky part, and where Steve and I left off.
> >   
> 

I think it's possible. It still be tricky. We need to handle percpu
variables.  But I have some ideas on how to do it though.

> Fortunately the linker code should be pretty easy to make
> self-contained.   It shouldn't need to do memory allocations or anything
> complex like that, so I think its just a matter of grovelling around and
> fixing up linkages.

Well, we still need to make sure the kernel knows about this image, so
that it doesn't write over it.  I guess that can be done like the initrd
is.

> 
> > I suspect we could free the unused backends already.
> 
> We could; we just need to make sure they get their own section so
> they're easily separable.
> 
> >   It also has one
> > negative side-effect, which is promoting external module code that links
> > with the kernel.  IOW, there's much less incentive to get code merged
> > if it's just a matter of linking.
> 
> It wouldn't be something we'd promote by making it easy to bind
> out-of-tree code to the interface.  And it would still be a
> kernel-version-specific ABI; no guarantees of stability.

It will be very similar to how we handle modules (and out of tree
modules).

-- Steve

TODO

[Santosh G]

I was going through the Kernel Janitors TODO page and was wondering if
its current. There are quite a few things listed there but I am not
sure which ones are fixed/taken.

Can anyone advise on this ? It appears that the only way to know
whether a bug is fixed is to look at the code.

Thanks
Santosh

Re: TODO

[Randy Dunlap]

On Tue, 20 May 2008 10:44:35 -0700 Santosh G wrote:

> I was going through the Kernel Janitors TODO page and was wondering if
> its current. There are quite a few things listed there but I am not
> sure which ones are fixed/taken.
> 
> Can anyone advise on this ? It appears that the only way to know
> whether a bug is fixed is to look at the code.

It's also OK and advisable to ask on the mailing list before spending
time on a TODO item.

~Randy