iPXE discussion forum

Full Version: iPXE GSoC 2013 participation collaboration meeting (using Google+ Hangouts)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi everyone

So I called this Google+ Hangout meeting to discuss how we could participate in GSoC 2013. Some people had some technical issues to work out before they could attend, some had other problems with Google+, but eventually some people were able to attend.

The people attending were:

Robin Smidsrød (myself)
Matthew Helton (aka MultiMediaMan)
Andrew Bobulsky (aka RulerOf)
Marin Hannache (aka Mareo)
Brijesh Kumar (potential GSoC student that found us randomly)

I was asking around of what kind of skills people had and in what capacity they might consider to help out. None of the people present had any deep C skills, but we are all interested in automation, so we know some scripting language. Perl and PHP was mentioned.

Both myself, Andrew and Matthew mentioned positively that we might be able to mentor _something_ we are good at. Together with Michael Brown (mcb30) and Thomas Miletich (thomil) that are quite good at C I think we have enough people to apply. Shao Miller and John Hawley (warthog9) has also mentioned (earlier) that they'd be willing to backup the others a bit if needed, but not take on any primary responsibilites.

We discussed what potential ideas could be added to the http://ipxe.org/gsoc page, and this is what we came up with (slightly more organized then the discussion was):

1. IPv6 support
2. USB driver framework
3. Intel wireless driver
4. A revival of boot.kernel.org (or another similar service)
5. An iPXE-based file browser for FTP/NFS
6. Syntax highlighter for iPXE scripts
7. One-time LAN boot instrumentation from running OS

I'll try to summarize what was said about each topic in turn so we know what questions to address on the ideas page.

== IPv6 support ==

The current patch made by mouse is apparently not using proper async methodology, so it is not possible to merge in its current state. It is obvious for long-term usage that IPv6 support of some kind is high on the wish list for a lot of users. It is still unclear what kind of IPv6 features would have to be provided, and it is probably not realistic to do as a GSoC project because the effort is just too big and too hard to mentor. I still think it's worthwhile to put it on the page to give students something to think/dream about.

== USB driver framework ==

More and more machines these days come only with wireless and no Ethernet jack. For these machines, the only way to network boot is to use a USB-based Ethernet adapter. None of these devices are currently supported because we don't have a USB driver stack. If it is possible to implement, we'd be able to bridge access to all of our current drivers over USB, which would make a lot of things easier. This is also a big project, and probably outside the scope of GSoC, but also highly sought after. I've answered questions more times than I can recall where it came down to the fact that the hardware was not supported because it used USB.

== Intel wireless driver ==

So many machines these days comes with built-in Intel wireless (centrino) and wireless network boot is a very cool feature. For most people it is unfortunately unavailable because iPXE doesn't support the intel adapters. Getting a working Intel wifi driver that works with the current Core/Core2 architectures would open a lot of eyes everywhere.

== boot.kernel.org revival ==

We already have several sophisticated examples of menus at http://ipxe.org/examples, but what we don't have, is a service like boot.kernel.org was. Instead of using PXELinux, we now have an option to use iPXE and script a sophisticated solution that would allow recovery environments and installers to be booted straight over the internet, even with full security. The current examples are not very well structured, and to make it into a public service we need more generalization and better security. It was also mentioned that the service should be possible to clone into your own local system and modified without too much effort. It was also mentioned that we could try to generate virtual machine images already set up to provide a boot menu for your local network.

== iPXE-based file browser for FTP/NFS ==

This is a continuation of Marin's work from last year's GSoC, but really a separate project. It is basically a file browser that would allow you to pick the name of the kernel+initrd to boot, potentially specify arguments to them and then boot them. This should all happen interactively. Any file service that supports directory browsing should be usable.

== Syntax highlighter for iPXE scripts ==

As our iPXE scripts are getting bigger and bigger, it is getting harder and harder to maintain them. A syntax highlighter, or more generally a lexer/parser that can convert the ipxe script into an abstract syntax tree and enable features like syntax highlighting, code completion, context-sensitive help and such for various editors like vim, emacs, Notepad++, Eclipse or such would be very useful. Code folding and block jumping are also useful side-effects. Actually being able to verify if the script is valid _before_ you run it is also a useful thing to be able to do.

== One-time LAN boot instrumentation from running OS ==

Some BIOSes has the ability to be told to perform their next boot from the network using operating system tools. But a lot of BIOSes can't really do that. Create a solution that make it possible to instrument a running Linux and/or Windows machine to add an item to their boot menu that will boot the machine from the network the next time it starts. Andrew had some prior experience doing this thing, and it was a crude hack. Making this into something robust could be very useful.


It was also mentioned that the documentation on http://ipxe.org/ is good, but its more of a reference than a good tutorial on how to get a beginner started with network booting. I think we all agreed on the fact that getting started with network booting is REALLY, REALLY HARD! There are so many moving parts, DHCP, TFTP, PXE, HTTP, iSCSI, routing, BIOS/kernel handover and more that is very hard to get a good overview on. It is even harder to get it all configured to do what you want in your environment. I think we need more tutorial information, better introduction material that contains a visual overview (i.e. we need help from someone that knows how to draw or make good diagrams).

I also mentioned that I had been thinking about doing Google+ Hangouts On Air with the title "Q/A - How to get started with network booting and iPXE" were beginners could come in and ask questions on how to do things and we could answer those questions, possibly with examples and live demos. Since these sessions would be recorded and published on YouTube it would get us more publicity. My main challenge with this is basically how to get the word out. I was thinking about posting in the appropriate Reddit forums and Google+ communities, but to get more people to come I think we need to use our joint force in getting the word out.

Overall it was a great experience, and everyone involved was very into trying to do it again. My plan is to invite again in about a week, but then have a more general topic than GSoC (or possibly no topic). I hope more of you'll be able to attend. My plan is to start somewhere around 16:00 or 17:00 UTC, as that should enable most people in both Europe and America to attend during daytime. If you'd very much like to attend, please tell me what day of the week and time would work best for you.

Let's do it again!

-- Robin
Thanks a lot for this summary, and for your co-ordination efforts, Robin. Smile I'm upset that I missed today's discussion, but glad that you shared this post.

I'm just starting a new job and wish to focus on it, so any time between 09:00 EDT/13:00 UTC and 23:00 EDT/03:00 UTC on Saturday and 09:00 EDT/13:00 UTC and 18:00 EDT/22:00 UTC on Sunday are times that I'd be available and happy to discuss iPXE GSoC business!

Yes, if I've a computer and Internet during GSoC, I will be hanging around the FreeNode #ipxe IRC channel and trying to help with whichever iPXE projects might be underway. I regret that I cannot commit to being a mentor, this year, due to some other commitments.
robinsmidsrod Wrote:== IPv6 support ==

The current patch made by mouse is apparently not using proper async methodology, so it is not possible to merge in its current state. It is obvious for long-term usage that IPv6 support of some kind is high on the wish list for a lot of users. It is still unclear what kind of IPv6 features would have to be provided, and it is probably not realistic to do as a GSoC project because the effort is just too big and too hard to mentor. I still think it's worthwhile to put it on the page to give students something to think/dream about.
could you please provide a link to the proper example of async methodology used in iPXE's drivers.

Thank you.
mouse: I'm not entirely sure what the actual problem is, as I just heard a comment that the code was using blocking I/O in places you shouldn't do that. I'm not a C coder, mostly just a sophisticated user and community manager, so it would be unwise to try and pretend I know something about it and point you at specific code. For more details, I would ask that question on the mailing-list.
For those of you that wasn't there, here is the discussion thread on why we were rejected from this year's GSoC. Hopefully this is food for thought for any future participation.

<w9|copyleft|ipxe> got time for ipxe too?
<carols> yes i do.
<carols> hold on just a sec.
<w9|copyleft|ipxe> (sine I'm the nominated stand-in for both orgs)
<carols> ah, so this was a different case.
<carols> we really liked ipxe's ideas page and ideas.
<carols> and application.
<carols> but this year, like most years, we always struggle with the open source hardware space.
<carols> i completely understand that a lot of it can be done without hardware.
<w9|copyleft|ipxe> that being said at least having a chunk of hardware does help
<carols> but it's sort of a point not in your favor if the students might need hardware in order to participate.
<carols> and the bar was already set high this year from the other orgs' applications.
<w9|copyleft|ipxe> fair enough, would it help (in the future) if we offered to provide hardware?
<carols> somewhat.
<w9|copyleft|ipxe> we'll keep that in mind
<carols> but what about customs issues getting it to remote places?
<carols> and what if it's broken in shipping?
<w9|copyleft|ipxe> well network cards are fairly small, but the point is taken
<carols> and how does the student prove they've got the chops for the project without the hardware? and do you delay the project if it gets stuck in shipping somewhere?
<carols> anyway
<carols> it's not insurmountable
<carols> but it's just a higher bar
<carols> and so when we were making tough decisions already…
<w9|copyleft|ipxe> fair enough :-)
<carols> :-)
<w9|copyleft|ipxe> we'll try again next year
<carols> awesome, please do.
<w9|copyleft|ipxe> and might find another umbrella org to hide under again
<carols> thanks again for waiting.
<w9|copyleft|ipxe> no prob
<carols> cool :-)
<carols> i hope you have a nice weekend
<w9|copyleft|ipxe> you too!
<carols> cheers
<carols> moving along
<carols> !nextinline
Reference URL's