FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 01-18-2011, 06:49 PM
Chris Lumens
 
Default loader+pykickstart integration preview

I spent all last week working on a set of patches to convert loader to
using pykickstat. The motivation for this was a bug report stating that
you can't use "reboot" in a file that gets %included, because the
kickstart parser in loader doesn't understand %include. When I started
pykickstart, the point was to get rid of the separate parser in s-c-ks.
We still have that problem, but now anaconda is to blame.

So what I've done is embed python in loader so kickstart.c is just
calling into pykickstart. The resulting patch set is not necessarily
smaller than what we've got now, due to all the C/Python type
conversions. It's also not necessarily less complex. However, it is
one less kickstart parser in the world.

Here's what I've got so far:

http://clumens.fedorapeople.org/python/

I still have a little way to go, but I'm interested in opinions on
whether this is useful or not.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-19-2011, 10:23 AM
Radek Vykydal
 
Default loader+pykickstart integration preview

On 01/18/2011 08:49 PM, Chris Lumens wrote:

I spent all last week working on a set of patches to convert loader to
using pykickstat. The motivation for this was a bug report stating that
you can't use "reboot" in a file that gets %included, because the
kickstart parser in loader doesn't understand %include. When I started
pykickstart, the point was to get rid of the separate parser in s-c-ks.
We still have that problem, but now anaconda is to blame.

So what I've done is embed python in loader so kickstart.c is just
calling into pykickstart. The resulting patch set is not necessarily
smaller than what we've got now, due to all the C/Python type
conversions. It's also not necessarily less complex. However, it is
one less kickstart parser in the world.

Here's what I've got so far:

http://clumens.fedorapeople.org/python/

I still have a little way to go, but I'm interested in opinions on
whether this is useful or not.




Overall I like it, but I have one concern - would we be able
to handle (execute) multiple network commands in loader
on top of this changes? Like by adding some mechanism
similar to KickstartData and execute(). Perhaps access
to NetworkData objects stored in _dataObjs with some
logic in loader can do. I am just making sure it won't be
big problem because I have some patches for networking
requiring this in queue.

Radek

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-19-2011, 10:34 AM
Radek Vykydal
 
Default loader+pykickstart integration preview

On 01/19/2011 12:23 PM, Radek Vykydal wrote:


Overall I like it, but I have one concern - would we be able
to handle (execute) multiple network commands in loader
on top of this changes? Like by adding some mechanism
similar to KickstartData and execute(). Perhaps access
to NetworkData objects stored in _dataObjs with some


I mean access to KicstartData objects.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-19-2011, 02:08 PM
Chris Lumens
 
Default loader+pykickstart integration preview

> Overall I like it, but I have one concern - would we be able
> to handle (execute) multiple network commands in loader
> on top of this changes? Like by adding some mechanism
> similar to KickstartData and execute(). Perhaps access
> to NetworkData objects stored in _dataObjs with some
> logic in loader can do. I am just making sure it won't be
> big problem because I have some patches for networking
> requiring this in queue.

Yes. Maybe it's not clear from the patch, though. If you look at the
new setKickstartNetwork in patch #6, you will see a call to getDataList
close to the top. This grabs the list of data objects. Then, I walk
that list and do stuff for each one. So I'm taking care of multiple
network commands like that.

My real question about this is how much stuff should I do for each
network command. I likely don't want to be setting loaderData
attributes for each. Consider the following:

network --bootproto=dhcp --device=eth0
network --ip=1.2.3.4 --gateway=5.6.7.8 --device=eth1

If I apply settings to loaderData for each of these lines, loaderData
will end up reflecting the combination of the two. No good.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-20-2011, 08:18 AM
Radek Vykydal
 
Default loader+pykickstart integration preview

On 01/19/2011 04:08 PM, Chris Lumens wrote:

Overall I like it, but I have one concern - would we be able
to handle (execute) multiple network commands in loader
on top of this changes? Like by adding some mechanism
similar to KickstartData and execute(). Perhaps access
to NetworkData objects stored in _dataObjs with some
logic in loader can do. I am just making sure it won't be
big problem because I have some patches for networking
requiring this in queue.


Yes. Maybe it's not clear from the patch, though. If you look at the
new setKickstartNetwork in patch #6, you will see a call to getDataList
close to the top. This grabs the list of data objects. Then, I walk
that list and do stuff for each one. So I'm taking care of multiple
network commands like that.



Ah, sorry, I didn't expect it there so I didn't see it.


My real question about this is how much stuff should I do for each
network command. I likely don't want to be setting loaderData
attributes for each. Consider the following:

network --bootproto=dhcp --device=eth0
network --ip=1.2.3.4 --gateway=5.6.7.8 --device=eth1

If I apply settings to loaderData for each of these lines, loaderData
will end up reflecting the combination of the two. No good.




That is really good point. I need to check this in my patches too.
Maybe it is time to rework it more thoroughly - not to pass the
values through loaderData, but use ifcfg structure right away
(not for rhel6 probably). Otherwise really a lot of loaderData
initialization has to happen in network command handler.
And yes, even more setting will be needed with your patch as
formerly some loaderData were updated right in process of parsing

And then again - ouch - some behaviour, like using device set
in cmdline for network command with unspecified device collide
with resetting of former value of lodaderData->device in network
command handler.

If you don't to want bother with it now, just use only the first network
command in your handler and ignore the others (that's the behaviour now)
and I'll either port my multiple network command patch on top of it,
or if I push earlier, I'll update my patch to reset loaderData values
(or use iface structure) and later review carefully (or take care of) your
setKickstartNetwork patch.


Radek


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-20-2011, 02:24 PM
Chris Lumens
 
Default loader+pykickstart integration preview

> If you don't to want bother with it now, just use only the first network
> command in your handler and ignore the others (that's the behaviour now)
> and I'll either port my multiple network command patch on top of it,
> or if I push earlier, I'll update my patch to reset loaderData values
> (or use iface structure) and later review carefully (or take care of) your
> setKickstartNetwork patch.

Yeah, I was going to just use the first network device for now. We can
work on getting the new behavior set up later. I think we're going to
have to think about that for a while.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 08:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org