Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
soc:ideas [2009/03/19 08:28]
stefanha
soc:ideas [2011/03/26 13:34] (current)
genec [What you will need] point to git-usage instead of info here.
Line 17: Line 17:
 If you are feeling more adventurous,​ and have access to appropriate hardware, you could: If you are feeling more adventurous,​ and have access to appropriate hardware, you could:
  
-  * :-/ :-/ :-/ :-/ Add a driver for a wireless network card.  There is some out-of-date support for one type of 802.11b wireless card; you could expand this into general framework for wireless networking, and add drivers for one or more modern wireless NICs.+  * :-/ :-/ :-/ :-/ Add a driver for a wireless network card. (gPXE has an 802.11 stack similar to simplified version of Linux'​s,​ but wireless networking ​cards tend to be trickier than wired ones.)
  
   * :-/ :-/ :-/ Add a non-Ethernet driver, e.g. a driver for an Infiniband card.  (gPXE does have a working Infiniband subsystem.)   * :-/ :-/ :-/ Add a non-Ethernet driver, e.g. a driver for an Infiniband card.  (gPXE does have a working Infiniband subsystem.)
Line 24: Line 24:
  
   * :-/ :-/ :-/ :-/ Add support for a new bus type, e.g. PCMCIA or USB.   * :-/ :-/ :-/ :-/ Add support for a new bus type, e.g. PCMCIA or USB.
- 
-==== Protocols ==== 
- 
-gPXE already supports several common (and less common) protocols, including TFTP, FTP, HTTP, HTTPS, DNS, iSCSI and AoE.  There are several more (mostly fairly esoteric) protocols that people may find useful. ​ You could add support for: 
- 
-  * :-/ :-/ Fibre Channel over Ethernet (FCoE) 
- 
-  * :-/ :-/ Novell'​s Remote Program Load (RPL) 
- 
-  * :-/ :-/ iSCSI extensions for RDMA (iSER) 
  
 {{:​nullmodem.jpeg?​200×200 |A null-modem cable}} {{:​nullmodem.jpeg?​200×200 |A null-modem cable}}
Line 39: Line 29:
 ==== Automated regression testing ==== ==== Automated regression testing ====
  
-:-/ :-/ :-/ :-/ :-/ gPXE has a relatively large feature set given the code size.  Many features are rarely used, and there has been a tendency for parts of the code to suffer from bit-rot. ​ The measures we have taken so far will ensure that we never end up with unbuildable code; we now avoid the use of #ifdef wherever possible, and have automated tests in place to identify missing or redundant symbols. ​ However, we do not have any systematic method for functional testing. ​+:-/ :-/ :-/ :-/ gPXE has a relatively large feature set given the code size.  Many features are rarely used, and there has been a tendency for parts of the code to suffer from bit-rot. ​ The measures we have taken so far will ensure that we never end up with unbuildable code; we now avoid the use of #ifdef wherever possible, and have automated tests in place to identify missing or redundant symbols. ​ However, we do not have any systematic method for functional testing. ​
  
 We would ideally like to be able to run a series of tests to verify different functional units (e.g. http download, Linux kernel booting, PXE booting, serial console support, etc.). ​ Most of these tests can be carried out inside a virtual machine such as bochs or qemu.  Some tests (e.g. specific device driver tests) will need to be carried out on real hardware. ​ The tests should be fully automated, and should produce a clear pass/fail status indicator. ​ It should be possible for a developer to simply run “make test” and, some time later, receive an overall pass/fail status, together with a list of any failed tests. We would ideally like to be able to run a series of tests to verify different functional units (e.g. http download, Linux kernel booting, PXE booting, serial console support, etc.). ​ Most of these tests can be carried out inside a virtual machine such as bochs or qemu.  Some tests (e.g. specific device driver tests) will need to be carried out on real hardware. ​ The tests should be fully automated, and should produce a clear pass/fail status indicator. ​ It should be possible for a developer to simply run “make test” and, some time later, receive an overall pass/fail status, together with a list of any failed tests.
Line 47: Line 37:
 Having such an automated test suite would enable us to offer quality control guarantees; we could then be confident that upgrades would not break existing functionality. Having such an automated test suite would enable us to offer quality control guarantees; we could then be confident that upgrades would not break existing functionality.
  
-==== IPv6 Support ​====+==== Improved TCP performance ​====
  
-:​-/:​-/:​-/ ​One of the many strong dependencies on IPv4 is the PXE specificationBy having Ipv6 support available in gPXE would make the dependency on IPv4 PXE a non-issue in some environments ​and only a minor dual-stack inconvenience ​in larger data center deployments +:-/ :-/ :-/ gPXE includes support for the Transmission Control Protocol underlying most of the Internet'​s traffic, enabling network boot files to be loaded over reliable protocols like HTTP and iSCSITo keep the code small, though, gPXE's TCP stack is very simple, ​and does not support many TCP features such as out-of-order packet recovery, selective ACK, window scaling, or congestion control. Implementing some of these features would allow much better performance ​in downloads of large network boot images.
  
-gPXE already has the IPv6 framework in place but doesn'​t have support for state-less/​full IPv6 DHCP. The most basic requirement would be stateless DHCP and stateful DHCP for the DNS servers. ​ As with all IPv6 support, it would be preferred over IPv4 communications,​ attempted first, and perform AAAA lookups over A lookups ​in DNS.+You would analyze ​the performance benefits ​and code size costs of several TCP features, and choose a few to implement ​in gPXE's TCP stack to best improve performance without compromising gPXE's ability to fit into ROM.
  
-==== ProxyDHCP server for Linux ====+==== Security improvements ​====
  
-:-/ :-/ ProxyDHCP provides ​mechanism for supplying DHCP options to clients independently of IP addresses. ​ It is a PXE extension to DHCP, and is already supported ​by gPXE It is potentially useful in situations such as adding ​a network ​booting infrastructure ​to a network that already has DHCP server ​that cannot be reconfigured (This is a fairly typical problem in corporate networks.)+:-/ :-/ :-/ (:-/) gPXE currently supports loading boot files over TLS-secured HTTP connection (''​%%https://​%%''​ URI), but the implementation ​is sufficiently skeletal that its security is much less than that of typical Web browser: 
 +  * gPXE has no boot-time source of entropyso its random numbers are not really random ​and could be guessed fairly easily ​by an attackerYou would implement ​cryptographically strong random number generator (algorithms for several are publicly available), using entropy from timing jitter in the system clock or the timing of packet arrivals on the network
 +  * We do not verify the server'​s certificate,​ so there is no way to be sure traffic to the secure server is not being hijacked by third party. You would implement support for compiling gPXE with root Certificate Authority, such that it would only allow secured connections to servers bearing certificates signed by that authority. This would require parsing the x509 certificate'​s ASN1 representation to extract the cryptographic data necessary for verification,​ and performing the appropriate signature verification to ensure the certificate really was signed by the CA.
  
-There is currently no open source ProxyDHCP server software ​It ​would be desirable ​to extend ISC dhcpd to provide this functionality. ​ ISC dhcpd already has a rich configuration file syntax including ​the ability to perform conditional behavior depending on the contents of packets it receives. ​ It currently lacks the ability to offer DHCP options without simultaneously offering an IP address.+Either of these projects would require either a preexisting familiarity with cryptography or a week or two of research into the necessary methods and data formats. Familiarity with C is required, and a moderate mathematical background probably helpfulThe results ​would enable sites with stringent data security requirements ​to begin using gPXE to boot their systems over the network.
  
-You would extend ISC dhcpd to be able to support operation as a ProxyDHCP server. ​ This would include designing appropriate extensions to the dhcpd.conf syntax, implementing and testing the changes, and working with the dhcpd maintainers to get your changes integrated upstream.+==== Linux Distribution network installation ====
  
-Having this ability would make it easier ​for users to deploy gPXE in large corporate networks ​with restrictive policies on changes ​to the DHCP infrastructure.+:-/ :-/ Most Linux distributions include some support ​for installation over the network. ​ In most cases, this is designed ​to work with a standard PXE stack supporting only TFTP, but requires only a few small tweaks (and several days of testing) in order to work directly over HTTP.  Installation via HTTP would provide a much smoother and simpler experience for the user.
  
-==== Enhanced scripting language ====+Some distributions also provide support for installation directly to an iSCSI target. ​ This support tends to be fragile and difficult to use, and the instructions necessary to get it to work tend to be complex. ​ It would be nice if installation to an iSCSI target worked at least as well as it currently does in Windows Server 2008.
  
-:-:-:-/ gPXE has a [[:​commandline|command language]] that allows users to boot interactively but is also used for scripts.  ​Scripts allow users to customize gPXE behavior for site-specific network and boot configurations.+You would work to improve the network installation and iSCSI target installation capabilities of several of the major Linux distributions (Fedora/CentOS/RHEL, Ubuntu, etc).  The installers tend to vary substantially between distributions,​ so work done on one distribution will not usually be directly usable on another.  ​You would liaise with the relevant distribution maintainers ​to get your changes merged upstream into the next releases of each distribution.
  
-There is currently no support for loopingconditional branches, or the arithmetic ​and string manipulation operators that allow powerful scripts to be written. ​ Enhancing gPXE scripting with these language constructs will make it possible ​for users to implement advanced boot policies without modifying ​gPXE's source code.+Having this support ​would make life easier ​for users attempting to install Linux over the network, and would provide an incentive ​for NIC and motherboard vendors ​to ship gPXE in place of a legacy PXE ROM.
  
-You would design a scripting language with input from the gPXE community to make advanced boot use cases possible. ​ You would then implement, test, and document the language so it can be included in mainline gPXE.  This task will require good C programming skills, an interest in the design and implementation of languages, and an appreciation for real-world challenges such as fitting a powerful language into an environment with a tiny code size budget.+==== IPv6 Support ====
  
-Having a powerful scripting language would make it possible to customize network boot behavior without being an expert in low-level C programming and gPXE internals.+:-/ :-/ :-/ gPXE currently contains an aborted attempt at an IPv6 implementation. ​ Several other attempts have been made over the past few years; none have been of sufficient quality to be merged into the main tree.
  
-See this [[:dev/​scripting/​start|brainstorming page]] for an idea of how such a language could look.+gPXE is structured to allow easy addition of IPv6the IPv4 layer is cleanly separated from both the transport layers (TCP and UDP) and the link layers (Ethernet and others). ​ Adding IPv6 support would require implementation ​of the basic IPv6 network layer protocol plus any ancillary protocols required for IPv6 operation ​such as NDP.  The existing DNS protocol support should be extended to cover IPv6 AAAA records, and it would also potentially be useful to support DHCPv6.
  
-==== R.O.M. - Rom-O-Matic ​====+==== ProxyDHCP server for Linux ====
  
-:-/ Rom-O-Matic is the web graphical fronted ​to creating Etherboot & gPXE romsthere are several things that need to be worked on within the code base to make it better & more user friendly+:-/ :-/ ProxyDHCP provides a mechanism for supplying DHCP options ​to clients independently of IP addresses. ​ It is a PXE extension to DHCPand is already supported by gPXE.  It is potentially useful in situations such as adding a network booting infrastructure ​to a network that already has a DHCP server that cannot ​be reconfigured. ​ (This is a fairly typical problem in corporate networks.)
  
-  * Updating and merging of the new configuration file reading code originally done by John 'Warthog9' ​Hawley +''​dnsmasq''​ is currently the only open-source DHCP server that supports Proxy DHCPbut it is not designed to be scalable to very large networks such as those found at corporate installationsIt would be desirable to extend ISC dhcpd to provide this functionality as wellISC dhcpd already has a rich configuration file syntax including the ability to perform conditional behavior depending on the contents of packets it receives.  ​It currently lacks the ability to offer DHCP options without simultaneously offering an IP address.
-  * Updating configuration files to includeinline, syntax information hints for things like R.O.M. +
-  * Trivial ROM creation based on relative place in gPXE source tree +
-  * User Interface clean-ups+
  
-Knowledge of gPXE building & configuration,​ ability ​to read and understand C and programing in php are required.+You would extend ISC dhcpd to be able to support operation as a ProxyDHCP server. ​ This would include designing appropriate extensions to the dhcpd.conf syntax, implementing ​and testing the changes, ​and working with the dhcpd maintainers to get your changes integrated upstream.
  
-==== boot.kernel.org - Universal remote network booting ​for the masses ====+Having this ability would make it easier ​for users to deploy gPXE in large corporate networks with restrictive policies on changes to the DHCP infrastructure.
  
-**Note:** This is cross posting on both Etherboot.org ​and Syslinux as the project ​is, literally, a cross disciplinary project. ​ Please also see [[http://​syslinux.zytor.com/​wiki/​index.php/​Google_Summer_of_Code_Ideas|Syslinux'​s SOC]] idea'​s ​page as an applicant will be working closely ​with both projects.+==== Enhanced scripting language ==== 
 + 
 +:-/ :-/ :-/ gPXE has [[:​commandline|command language]] that allows users to boot interactively ​and is also used for scripts. ​ Scripts allow users to customize gPXE behavior for site-specific network and boot configurations. 
 + 
 +For last year's Summer of Code[[:​soc:​2009:​lynusvaz:​start|Lynus Vaz]] added support for loopingconditional branches, and arithmetic and string manipulation operators to allow more powerful scripts to be written; there is a [[:soc:​2009:​lynusvaz:​notes:​scripting_doc:​features_added|description of features added]] available. The idea was to make it possible for users to implement advanced boot policies without modifying gPXE'​s ​source code. Unfortunately,​ these features came with a large code size cost, and a single-driver build of gPXE generally has to fit in 64kB to be useful to ROM users. 
 + 
 +You would modify the implementation of this advanced scripting language with an eye towards achieving the minimum code size possible. You would be able to modify the design of the language as necessary to be amenable to these constraints, ​with input from the gPXE community. Large sections of the code would probably need to be rewritten. This task will require good C programming skills, ideally some experience in the design and implementation of simple languages, and a strong appreciation for the real-world challenge of fitting a powerful language into an environment with a tiny code size budget. 
 + 
 +Having a powerful scripting language would make it possible to customize network boot behavior without being an expert in low-level C programming and gPXE internals.
  
-:-/ :-/ The basic idea for boot.kernel.org is to provide a universal location for basic computer system tasks such as: +==== Improved debugging support ====
-  * Run Diagnostics +
-    * Memory Testers +
-    * Hard Drive Testers +
-    * CPU / Memory "​burn-in"​ testers +
-  * Get System information +
-    * Display PCI Layouts +
-    * Display Hardware attached to the system +
-  * Install network installable OSes +
-    * Linux - a specific and primary goal, listings should be able to auto-update,​ etc +
-      * Fedora +
-      * CentOS +
-      * Debian +
-      * Ubuntu +
-      * OpenSuse (**NOTE:** assuming this can be done sanely) +
-      * Classic Distros +
-      * etc, specific emphasis on distro'​s available at mirrors.kernel.org +
-    * Other OSes could be added but not explicitly a requirement +
-      * BSD based distro'​s +
-      * OpenSolaris +
-      * etc +
-The work that would need to go into making this happen is going to be based on an existing project called [[http://​pxeknife.erebor.org|PXE Knife]] which is already in the process of breaking up it's components into various states to allow for a subset to be included on Kernel.org+
  
-boot.kernel.org will need to provide a simple and easy mechanism to generate a custom CDfloppy ​or usb stick image that can be trivially loaded by an end user This custom CD will be based on the Etherboot project'​s ​gPXE code and may include additions from the Syslinux project as well.+:-/ :-/ :-/ :-/ :-/ gPXErunning as it does in an environment with nothing by way of memory protection ​or operating system services, ​can be very difficult to debugWe have a GDB stub to allow remote debugging over a serial cable or UDP, but for architectural reasons it'​s ​impossible to detect invalid memory accesses or interrupt infinite loops with itThere are a couple of ways of making this work:
  
-This is a very interdisciplinary projectneeding and involving an understanding ​of the entirety of Syslinux (configuration of both text and graphical interfaces including menu.c32 and vesamenu.c32,​ memdisk, etc), Web programing for customized menuing options (preference for php or perl), a solid understanding of gPXE and how network booting works, along with a good understanding of Linux network booting.+  * Allow gPXE to run with paging enabledidentity-mapping only those parts of the address space that are validThis would require significant expertise in low-level x86 internals; ​gPXE interacts ​with them even more than typical operating system, because it has to regularly switch between real and protected mode to perform BIOS calls.
  
 +  * Allow gPXE to run as a user-mode application under Linux. Obviously network card drivers would be difficult to test in this environment,​ but most other parts of gPXE could be run in an environment with built-in memory protection and useful tools like ''​valgrind''​ easily available. The cleanest way to do this would be to create another x86 "​platform",​ alongside the existing PC-BIOS and EFI, that performs low-level Linux system calls to perform platform-specific operations. A Linux kernel module could be used to enable DMA for testing network card drivers. The prospective implementor would need a fair amount of low-level Linux kernel experience.
  
 ===== What you will need ===== ===== What you will need =====
Line 126: Line 103:
   * A development machine, running Linux, that you have root access to.  You will edit and compile gPXE on this machine, and you may also need to set up software such as a DHCP server etc.  (We will talk you through getting your machine set up for development;​ the important thing is that you must have a machine available.)   * A development machine, running Linux, that you have root access to.  You will edit and compile gPXE on this machine, and you may also need to set up software such as a DHCP server etc.  (We will talk you through getting your machine set up for development;​ the important thing is that you must have a machine available.)
  
-  * A testing machine, which you can reboot very frequently. ​ You will test gPXE on this machine. ​ This machine cannot be the same as your development machine; it must be a separate computer.+  * A testing machine, which you can reboot very frequently. ​ You will test gPXE on this machine. ​ This machine cannot be the same as your development machine; it must be a separate computer ​(or a virtual machine).
  
   * A working network between the two machines.   * A working network between the two machines.
  
   * Access to IRC (Internet Relay Chat), so that you can talk to us.   * Access to IRC (Internet Relay Chat), so that you can talk to us.
 +
 +  * We use git for source code management, so you will need to learn to create and manipulate your own git repository.
 +    * [[:​git-usage|Using git for gPXE development]]
  
 Depending on the project idea that you choose, you may also need: Depending on the project idea that you choose, you may also need:
Line 150: Line 130:
 Second, introduce yourselves to us.  Preferably via the IRC channel, though e-mail is perfectly acceptable. ​ We will want to spend some time talking to you about your proposal. ​ We will base our decision mostly on the interactions we have with you, rather than on the project proposal you submit via the GSoC web interface. Second, introduce yourselves to us.  Preferably via the IRC channel, though e-mail is perfectly acceptable. ​ We will want to spend some time talking to you about your proposal. ​ We will base our decision mostly on the interactions we have with you, rather than on the project proposal you submit via the GSoC web interface.
  
-Thirdly, once you've talked to us on IRC or via e-mail, submit a project proposal via the official Summer of Code web interface. ​ Your proposal should clearly state the project idea you'd like to work on, and should give some background information on your experience, and a rough overview of how you would approach the problem. ​ We will interview all applicants ​(via IRC), and our decision on who to accept will be based primarily on the interview ​(and on any other contact we've had with you via IRC).+Thirdly, once you've talked to us on IRC or via e-mail, submit a project proposal via the official Summer of Code web interface. ​ Your proposal should clearly state the project idea you'd like to work on, and should give some background information on your experience ​(including code samples if possible), and a rough overview of how you might approach the problem. 
 + 
 +We will interview all applicants via IRC in a private channel. ​ The interview will start with a discussion about your past coding experience, including a brief review of any code samples that you submitted along with your proposal. ​ We will then move on to two or three coding exercises for you to complete during the interview; you can view a [[:​soc:​2008:​memsearch|sample]] of one exercise used in last year's interviews. ​ We will also talk with you briefly about your proposed project. 
 + 
 +Our primary interest in the interview is to establish whether or not you are capable of writing clean, efficient C code (or another language, if appropriate for your project).  We will also want to see how you react to criticisms, hints, and suggestions. ​  ​Our ​decision on whom to accept will be based primarily on the interview, rather than your written proposal.
  
 ===== Hints and tips ===== ===== Hints and tips =====
Line 163: Line 147:
  
   * Main page: [[http://​code.google.com/​soc/​]]   * Main page: [[http://​code.google.com/​soc/​]]
-  * Student FAQ: [[http://​socghop.appspot.com/​document/​show/​program/google/gsoc2009/faqs]] +  * Student FAQ: [[http://​socghop.appspot.com/​document/​show/​gsoc_program/google/gsoc2010/faqs]] 
-  * Student Application:​ [[http://​socghop.appspot.com/​]] ​+  * Student Application:​ [[http://​socghop.appspot.com/​document/​show/​program/​google/​gsoc2009/​userguide#​depth_students]] 
  
 ==== Etherboot Project Links ==== ==== Etherboot Project Links ====
Line 171: Line 155:
   * Source Code: [[http://​www.etherboot.org/​wiki/​download]]   * Source Code: [[http://​www.etherboot.org/​wiki/​download]]
  
-==== Etherboot ​Mailing List Links ====+==== Mailing List Links ====
  
-  * Etherboot-Discuss ​Mailing List Archives: [[http://sourceforge.net/mailarchive/forum.php?​forum=etherboot-discuss]] +  * gPXE Mailing List: [[http://etherboot.org/mailman/listinfo/​gpxe]] 
-  * Etherboot-Discuss Mailing List Subscription Page: [[https://lists.sourceforge.net/​lists/​listinfo/​etherboot-discuss]]+  * Old Etherboot-Discuss Mailing List Archives: [[http://​sourceforge.net/​mailarchive/forum.php?​forum=etherboot-discuss]]
  
 ==== Etherboot IRC Channel ==== ==== Etherboot IRC Channel ====
Line 180: Line 164:
   * ''#​etherboot''​ on the FreeNode network (irc.freenode.net)   * ''#​etherboot''​ on the FreeNode network (irc.freenode.net)
  
 +==== Mentor Email ====
 +
 +  * You can reach us at [[soc-mentors@etherboot.org]],​ though IRC is preferred for most interactions.
  
  
 We hope you have enjoyed reading about the [[http://​www.etherboot.org/​|Etherboot Project]], and we look forward to meeting you and discussing your project ideas. We hope you have enjoyed reading about the [[http://​www.etherboot.org/​|Etherboot Project]], and we look forward to meeting you and discussing your project ideas.

QR Code
QR Code soc:ideas (generated for current page)