etherboot-developers Mailing List for Etherboot (Page 3)
Brought to you by:
marty_connor,
stefanhajnoczi
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(3) |
Oct
(10) |
Nov
(47) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(41) |
Feb
(107) |
Mar
(76) |
Apr
(103) |
May
(66) |
Jun
(72) |
Jul
(27) |
Aug
(31) |
Sep
(33) |
Oct
(18) |
Nov
(33) |
Dec
(67) |
2002 |
Jan
(25) |
Feb
(62) |
Mar
(79) |
Apr
(74) |
May
(67) |
Jun
(104) |
Jul
(155) |
Aug
(234) |
Sep
(87) |
Oct
(93) |
Nov
(54) |
Dec
(114) |
2003 |
Jan
(146) |
Feb
(104) |
Mar
(117) |
Apr
(189) |
May
(96) |
Jun
(40) |
Jul
(133) |
Aug
(136) |
Sep
(113) |
Oct
(142) |
Nov
(99) |
Dec
(185) |
2004 |
Jan
(233) |
Feb
(151) |
Mar
(109) |
Apr
(96) |
May
(200) |
Jun
(175) |
Jul
(162) |
Aug
(118) |
Sep
(107) |
Oct
(77) |
Nov
(121) |
Dec
(114) |
2005 |
Jan
(201) |
Feb
(271) |
Mar
(113) |
Apr
(119) |
May
(69) |
Jun
(46) |
Jul
(21) |
Aug
(37) |
Sep
(13) |
Oct
(4) |
Nov
(19) |
Dec
(46) |
2006 |
Jan
(10) |
Feb
(18) |
Mar
(85) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
(20) |
Aug
(9) |
Sep
(11) |
Oct
(4) |
Nov
(1) |
Dec
(40) |
2008 |
Jan
(19) |
Feb
(8) |
Mar
(37) |
Apr
(28) |
May
(38) |
Jun
(63) |
Jul
(31) |
Aug
(22) |
Sep
(37) |
Oct
(38) |
Nov
(49) |
Dec
(24) |
2009 |
Jan
(48) |
Feb
(51) |
Mar
(80) |
Apr
(55) |
May
(34) |
Jun
(57) |
Jul
(20) |
Aug
(83) |
Sep
(17) |
Oct
(81) |
Nov
(53) |
Dec
(40) |
2010 |
Jan
(55) |
Feb
(28) |
Mar
(36) |
Apr
(7) |
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
(10) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Michael B. <mb...@fe...> - 2010-03-26 14:00:56
|
On Thursday 25 Mar 2010 10:57:29 Alex Zeffertt wrote: > You're right, we can't break NTLDR. Here's an alternative way to fix the > problem. Now, I know this is a terrible hack... but it does guarrantee(*) > that non-Bootix NBPs will not be affected. :) I implemented a similar thing back in some ancient version of Etherboot: http://git.etherboot.org/?p=etherboot.git;a=blob;f=src/arch/i386/firmware/pcbios/hidemem.c;h=a9ae001e25992ea6fef0f16ecb939c9244179529;hb=f6f6bad3f6c42898235284d144b800456312e39b#l67 This hack was worse than yours; it involved having Etherboot edit the binary of the running NBP. Of couse, it was suitably protected by an #ifdef, so all was well and good. I've started a Win2k3 R1 install going, so I can set up a RIS server for testing against. Michael |
From: garg v. <vik...@ya...> - 2010-03-25 21:59:13
|
Hi..., this is Vikas Garg from India. I am an undergraduate student from computer science discipline. I have keen interest in open source etherboot/ gpxe project and really want to be part of it. I have keen interest in network booting which developed from my troubleshooting project on k12ltsp. I am writing this post to introduce myself and to take suggestions for project idea for gpxe. Idea: gpxe uses the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encryption and secure identification of the server and presently gpxe has not implemented server side certificate verification. Implementing certificates may be cumbersome and will require more debugging. Security requirements of gpxe can be full filled by using SFTP protocol (SSH) which has some advantages over HTTPS [1]. Presently, gpxe uses MD5, SHA1 for hash algorithms, AES (block cipher), ARC4 (stream cipher), CHAP as authentication protocol and X.509 for public key infrastructure (not implemented for server side certificates). It uses CBC (cipher block chaining) cipher mode operation. As CBC uses sequential method to encrypting blocks which results slow data transfer. Second, drawback is error propagation, means only one missing bit can corrupt whole data. CTR (counter mode) may be better as it resolve above drawbacks of CBC [2]. 1. Openssh 5.4 has added support for certificate authentication of users and hosts using anew, minimal OpenSSH certificate format (not X.509). Certificates contain a public key, identity information and some validity constraints and are signed with a standard SSH public key[3]. So, it may be good idea to extract necessary features of Openssh and implement for gpxe by sftp. 2. Openssh also provides data compression which may improve performance [4]. 3. Openssh implements AES with CTR mode. (From openssh code). [1] http://www.snailbook.com/faq/ssl.auto.html [2] http://osdir.com/ml/network.peer-to-peer.p2p-hackers/2006-11/msg00103.html[3] http://lwn.net/Articles/377703/ [4] http://www.openssh.com/features.html Regards Vikas Garg The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/ |
From: Alex Z. <ale...@eu...> - 2010-03-25 10:57:37
|
Michael Brown wrote: > On Wednesday 24 Mar 2010 12:02:44 Alex Zeffertt wrote: >> Perhaps the Bootix NBP shouldn't be doing this... but we've found that if >> we make PXENV_TFTP_READ_FILE only update the filename in >> cached_info[CACHED_INFO_DHCPACK] and leave the filename in >> cached_info[CACHED_INFO_BINL] then the boot succeeds. (See patch below.) >> >> If anybody is still reading, do you know whether this is an okay way to fix >> the problem, ... or will it break NTLDR? > > Nice debugging! > > Unfortunately I have no idea whether or not it will break NTLDR, and NTLDR > compatibility probably has to take higher priority than Bootix compatibility. > If you can verify that your change still allows a successful RIS deployment > (for which you would need Windows Server 2003 R1; I believe RIS was obsoleted > in 2003 R2 and replaced with WDS), then we could fairly safely apply this > change. > > I have Windows Server 2003 R1 media and licence keys, so could test this for > you, but I won't be able to do so any time soon, sorry. > > Michael > You're right, we can't break NTLDR. Here's an alternative way to fix the problem. Now, I know this is a terrible hack... but it does guarrantee(*) that non-Bootix NBPs will not be affected. Alex (*) sort of. |
From: Miller, S. <Sha...@yr...> - 2010-03-25 02:58:49
|
Uhh... I just tested disabling only the CACHED_INFO_DHCPACK filename overwrite, which also works in my setup... In fact, overwriting both CACHED_INFO_DHCPACK and CACHED_INFO_BINL's filename with "bar" at every call also works. This is with the SETUPLDR.EXE (as NTLDR) from XP SP2. I'm slightly wondering if the old symptom was due to the business addressed in Syslinux' commit 18ca4d8cc87761c6a5ab763069fad562fec69b59. I can't seem to track down where gPXE addresses this, but remember both you (Michael Brown) and Stefan Hajnoczi thinking about it. A related e-mail to refresh memories[1], in case it's a possibility. - Shao Miller [1] http://syslinux.zytor.com/archives/2009-August/013127.html |
From: Miller, S. <Sha...@yr...> - 2010-03-25 02:22:50
|
In regards to overwriting the CACHED_INFO_BINL filename with each pxenv_tftp_open(), pxenv_tftp_read_file(), pxenv_tftp_get_fsize(), pxenv_restart_tftp(): I have a setup that's a little different that I just tested removing the CACHED_INFO_BINL filename overwrite on, and it appeared to work. My setup does go through the motions of gPXE -> PXELINUX -> pxechain.com -> startrom.0 -> NTLDR -> many files via TFTP -> Windows, but doesn't use MS RIS as such. I have a DHCP service as well as a ProxyDHCP response, then I use pxechain.com. For what it's worth. Michael, I'm also curious if you happen to recall why performing the overwrite in pxenv_restart_tftp() was not sufficient and it was added to the rest of those calls. I know it's a while ago, now. :) - Shao Miller |
From: Michael B. <mb...@fe...> - 2010-03-25 00:50:28
|
On Wednesday 24 Mar 2010 12:02:44 Alex Zeffertt wrote: > Perhaps the Bootix NBP shouldn't be doing this... but we've found that if > we make PXENV_TFTP_READ_FILE only update the filename in > cached_info[CACHED_INFO_DHCPACK] and leave the filename in > cached_info[CACHED_INFO_BINL] then the boot succeeds. (See patch below.) > > If anybody is still reading, do you know whether this is an okay way to fix > the problem, ... or will it break NTLDR? Nice debugging! Unfortunately I have no idea whether or not it will break NTLDR, and NTLDR compatibility probably has to take higher priority than Bootix compatibility. If you can verify that your change still allows a successful RIS deployment (for which you would need Windows Server 2003 R1; I believe RIS was obsoleted in 2003 R2 and replaced with WDS), then we could fairly safely apply this change. I have Windows Server 2003 R1 media and licence keys, so could test this for you, but I won't be able to do so any time soon, sorry. Michael |
From: Miller, S. <Sha...@yr...> - 2010-03-24 21:50:28
|
Good day Meher, You had a question in regards to gPXE. Are you aware that there is a gPXE mailing-list? http://www.etherboot.org/wiki/mailinglists http://etherboot.org/mailman/listinfo/gpxe You might also enjoy the following links: http://www.etherboot.org/wiki/doc http://www.etherboot.org/share/sha0/gpxe/src/bin/doc/html/modules.html You can also keep in mind the GSoC mentors' e-mail address, given at: http://www.etherboot.org/wiki/soc/ideas#mentor_email Thanks very much for your interest! - Shao Miller |
From: Meher A. <meh...@gm...> - 2010-03-24 21:38:20
|
Hi. Question is - I want to be able to contribute to the "Improved TCP Performance" idea. I am well versed with Computer Networks. However, when I am looking at the source code right now, I can make out neither head nor tail out of it. If there is anyway I can get some sort of introductory tutorial/documentation regarding the code and the code architecture of gPXE, it would be really helpful to me. Regards. Meher Anand On Thu, Mar 25, 2010 at 2:49 AM, Kyle Kienapfel <ky...@sh...> wrote: > Its hard to help without a question to answer :) > > On Wed, Mar 24, 2010 at 1:59 PM, Meher Anand <meh...@gm...> > wrote: > > Hello all. > > > > I am currently studying in my 4th year of Computer Science & Engineering. > I > > am highly interested in contributing to gPXE as a developer. I have > > undergone courses of Operating Systems and Systems Programming and am > quite > > well versed with those areas. I also have a strong C/C++ programming > > background. I, however, need a headstart in order to understand the code > and > > thus be able to come up with an idea to implement a project topic. Please > > help me in this regard. > > > > Thanks. > > > > Meher Anand > > Visvesvaraya National Institute of Technology > > Nagpur, India > > > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > Etherboot-developers mailing list > > Eth...@li... > > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > > > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > |
From: Kyle K. <ky...@sh...> - 2010-03-24 21:19:26
|
Its hard to help without a question to answer :) On Wed, Mar 24, 2010 at 1:59 PM, Meher Anand <meh...@gm...> wrote: > Hello all. > > I am currently studying in my 4th year of Computer Science & Engineering. I > am highly interested in contributing to gPXE as a developer. I have > undergone courses of Operating Systems and Systems Programming and am quite > well versed with those areas. I also have a strong C/C++ programming > background. I, however, need a headstart in order to understand the code and > thus be able to come up with an idea to implement a project topic. Please > help me in this regard. > > Thanks. > > Meher Anand > Visvesvaraya National Institute of Technology > Nagpur, India > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Etherboot-developers mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-developers > > |
From: Meher A. <meh...@gm...> - 2010-03-24 20:59:56
|
Hello all. I am currently studying in my 4th year of Computer Science & Engineering. I am highly interested in contributing to gPXE as a developer. I have undergone courses of Operating Systems and Systems Programming and am quite well versed with those areas. I also have a strong C/C++ programming background. I, however, need a headstart in order to understand the code and thus be able to come up with an idea to implement a project topic. Please help me in this regard. Thanks. Meher Anand Visvesvaraya National Institute of Technology Nagpur, India |
From: Alex Z. <ale...@eu...> - 2010-03-24 15:52:14
|
It looks like PXENV_RESTART_TFTP updated the cached filename returned by PXENV_GET_CACHED_INFO for both PacketTypes from the start. I think the point at which interaction with Bootix broke must have been when PXENV_TFTP_READ_FILE was made to update the cache as well. Regards, Alex Miller, Shao wrote: > Good day again Alex, > > If it helps, here're a few commits in chronological order from most > recent to longest ago: > > Michael Brown [Sat, 2 Feb 2008 15:59:32 +0000 (15:59 +0000)] > The INFO_DHCPACK and INFO_BINL filenames were overwritten during > pxe_tftp_open() in commit 5e4e2671775b14122848368d1dbc3a26aec70d86. > > Michael Brown [Tue, 22 Jan 2008 18:51:12 +0000 (18:51 +0000)] > The code comments indicated that PXENV_TFTP_READ_FILE should also > overwrite the filename. Previously, only PXENV_RESTART_TFTP was > mentioned. I'm not too sure why this is. > > Michael Brown [Thu, 22 Nov 2007 04:43:11 +0000 (04:43 +0000)] > We can see the two memcpy()s introduced in commit > 838ecba1315a484f8e08f41a3537623dfd7f1966. I would have to follow the > code to find out if the behaviour included the INFO_BINL before this > point. > > Michael Brown [Sat, 30 Jun 2007 14:13:18 +0000 (15:13 +0100)] > The filename used in PXENV_RESTART_TFTP was used for > PXENV_GET_CACHED_INFO internally starting in commit > d05d8edd428efeff6c08dbd2423572de8e89ce06. > > - Shao Miller > |
From: Miller, S. <Sha...@yr...> - 2010-03-24 15:12:26
|
Good day again Alex, If it helps, here're a few commits in chronological order from most recent to longest ago: Michael Brown [Sat, 2 Feb 2008 15:59:32 +0000 (15:59 +0000)] The INFO_DHCPACK and INFO_BINL filenames were overwritten during pxe_tftp_open() in commit 5e4e2671775b14122848368d1dbc3a26aec70d86. Michael Brown [Tue, 22 Jan 2008 18:51:12 +0000 (18:51 +0000)] The code comments indicated that PXENV_TFTP_READ_FILE should also overwrite the filename. Previously, only PXENV_RESTART_TFTP was mentioned. I'm not too sure why this is. Michael Brown [Thu, 22 Nov 2007 04:43:11 +0000 (04:43 +0000)] We can see the two memcpy()s introduced in commit 838ecba1315a484f8e08f41a3537623dfd7f1966. I would have to follow the code to find out if the behaviour included the INFO_BINL before this point. Michael Brown [Sat, 30 Jun 2007 14:13:18 +0000 (15:13 +0100)] The filename used in PXENV_RESTART_TFTP was used for PXENV_GET_CACHED_INFO internally starting in commit d05d8edd428efeff6c08dbd2423572de8e89ce06. - Shao Miller |
From: Alex Z. <ale...@eu...> - 2010-03-24 14:18:53
|
Miller, Shao wrote: > > You mentioned that Bootix uses this area to store the next filename to > fetch. I am assuming that you mean the 128-byte filename array portion > of the cached packet structure, which is intended to hold a > nul-terminated string. I'm confused though... Did you mean that if > Bootix wants to fetch files A, B, in that order, that Bootix first > writes B into the cached packet, then calls PXENV_TFTP_READ_FILE but for > file A? Or did you mean that it puts A in the field, then calls > PXENV_TFTP_READ_FILE for A? Hi Shao, thanks for your reply. It looks like pxboot (the Bootix NBP) is using cached_info[CACHED_INFO_BINL].dhcphdr.file for its own purposes, and so things go awry when pxe_set_cached_filename() updates this field. In more detail: 1. At the start of day pxboot calls PXENV_GET_CACHED_INFO and gets a pointer to cached_info[CACHED_INFO_BINL]. 2. pxboot then writes "pxboot" into cached_info[CACHED_INFO_BINL].dhcphdr.file. 3. pxboot then calls PXENV_TFTP_READ_FILE with filename "8DFF5B8B.opt". This fails but has the side effect of calling pxe_set_cached_filename() to set cached_info[CACHED_INFO_DHCPACK].dhcphdr.file and cached_info[CACHED_INFO_BINL].dhcphdr.file to "8DFF5B8B.opt" 4. pxboot then calls PXENV_TFTP_READ_FILE with filename "8DFF5B8B.opt.opt". This fails. However, if we change pxe_set_cached_filename() so that it only updates cached_info[CACHED_INFO_DHCPACK].dhcphdr.file and leaves cached_info[CACHED_INFO_BINL].dhcphdr.file then the last event becomes 4. pxboot then calls PXENV_TFTP_READ_FILE for file "pxboot.opt". This succeeds. This leads me to think that pxboot is using its pointer to cached_info[CACHED_INFO_BINL].dhcphdr.file to save the name of the next file to get (minus the ".opt" extension). Now, from the comments above pxenv_tftp_read_file() it looks like the reason we are updating these two cached filenames is in order to emulate a bug in an Intel ROM that NTLDR relies on. However, the same comments *suggest* that we may be able to get away with only updating cached_info[CACHED_INFO_DHCPACK].dhcphdr.file. Does anyone know if this is true? I.e. is the patch I sent previously a safe way to fix the Bootix incompatibility? Regards, Alex |
From: Miller, S. <Sha...@yr...> - 2010-03-24 13:16:36
|
Good day Alex, You had a question in regards to gPXE. Are you aware that there is a gPXE mailing-list? http://www.etherboot.org/wiki/mailinglists http://etherboot.org/mailman/listinfo/gpxe You mentioned that the Bootix NBP has a SEG16:OFF16 pointer to the cached packet in PXE base code's data segment. As nearly as I can tell, this is according to spec. You mentioned that Bootix uses this area to store the next filename to fetch. I am assuming that you mean the 128-byte filename array portion of the cached packet structure, which is intended to hold a nul-terminated string. I'm confused though... Did you mean that if Bootix wants to fetch files A, B, in that order, that Bootix first writes B into the cached packet, then calls PXENV_TFTP_READ_FILE but for file A? Or did you mean that it puts A in the field, then calls PXENV_TFTP_READ_FILE for A? - Shao Miller |
From: Alex Z. <ale...@eu...> - 2010-03-24 12:02:53
|
Hi all, We've found that gPXE clients cannot boot successfully from a Bootix server. The problem appears to be to do with the cached filenames that gPXE saves and returns to the NBP when in response to a PXENV_GET_CACHED_INFO call. There are 3 such filenames: * from the last DHCP discovery (CACHED_INFO_DHCPDISCOVER) * from the last DHCP ACK (CACHED_INFO_DHCPACK) * from the last PXE request (CACHED_INFO_BINL) Now, when the Bootix NBP calls PXENV_GET_CACHED_INFO it doesn't provide a buffer. As a result gPXE returns a pointer to cached_info[CACHED_INFO_BINL] rather than copying this struct into a caller provided buffer. When the Bootix NBP calls PXENV_TFTP_READ_FILE gPXE updates the filenames in cached_info[CACHED_INFO_DHCPACK] and cached_info[CACHED_INFO_BINL]. According to the comments it does this because some Intel PXE implementation did this and even though this is a bug NTLDR depends on it. The problem is that the Bootix NBP has a pointer to cached_info[CACHED_INFO_BINL] and is using it to store the name of the next file to get! Perhaps the Bootix NBP shouldn't be doing this... but we've found that if we make PXENV_TFTP_READ_FILE only update the filename in cached_info[CACHED_INFO_DHCPACK] and leave the filename in cached_info[CACHED_INFO_BINL] then the boot succeeds. (See patch below.) If anybody is still reading, do you know whether this is an okay way to fix the problem, ... or will it break NTLDR? Regards, Alex --- pxe_preboot.c.orig 2010-03-24 10:27:50.000000000 +0000 +++ pxe_preboot.c 2010-03-24 10:28:13.000000000 +0000 @@ -111,22 +111,22 @@ * This is a bug-for-bug compatibility hack needed in order to work * with Microsoft Remote Installation Services (RIS). The filename * used in a call to PXENV_RESTART_TFTP or PXENV_TFTP_READ_FILE must * be returned as the DHCP filename in subsequent calls to * PXENV_GET_CACHED_INFO. */ void pxe_set_cached_filename ( const unsigned char *filename ) { memcpy ( cached_info[CACHED_INFO_DHCPACK].dhcphdr.file, filename, sizeof ( cached_info[CACHED_INFO_DHCPACK].dhcphdr.file ) ); - memcpy ( cached_info[CACHED_INFO_BINL].dhcphdr.file, filename, - sizeof ( cached_info[CACHED_INFO_BINL].dhcphdr.file ) ); +// memcpy ( cached_info[CACHED_INFO_BINL].dhcphdr.file, filename, +// sizeof ( cached_info[CACHED_INFO_BINL].dhcphdr.file ) ); } /** * UNLOAD BASE CODE STACK * * @v None - * @ret ... * */ |
From: Bill S. <wst...@hg...> - 2010-03-23 03:43:15
|
I've tried to add MCP79 Nvidia ethernet support (9400 chipset) by adding the PCI device id 0x0AB0 to forcedeth.c, but I don't think its working properly. All I really use etherboot for is sending a WOL packet to a server. I was wondering if anyone might might have some suggestions. |
From: Miller, S. <Sha...@yr...> - 2010-03-20 18:23:03
|
In an effort to iron out some licencing tracking, I've begun by adding the FILE_LICENCE() macro to some files where the licence was explicitly mentioned in the files themselves. A patch which addresses some "GPL version 2"-licenced files can be found in the staging repository at: http://git.etherboot.org/?p=gpxe-staging.git;a=commitdiff;h=d93dd91df09a 569deccfedab9375594e550da8c5 If you have a dispute, I welcome you to bring it forward. Thanks! - Shao Miller |
From: Miller, S. <Sha...@yr...> - 2010-03-20 17:28:50
|
In an effort to iron out some licencing tracking, I've begun by adding the FILE_LICENCE() macro to some files where the licence was explicitly mentioned in the files themselves. A patch which addresses some "GPL version 2 or later"-licenced files can be found in the staging repository at: http://git.etherboot.org/?p=gpxe-staging.git;a=commitdiff;h=25fa9819d1b3 92035b8f1e59d6020f784a8e01fc If you have a dispute, I welcome you to bring it forward. Thanks! - Shao Miller |
From: Marty C. <md...@et...> - 2010-03-12 11:44:39
|
Applied to gPXE main branch. Thanks Stefan, Masroor, and the whole Neterion team for your work. / Marty / Masroor Vettuparambil wrote on 3/5/10 5:11 AM: > Hi Stefan, > > Thanks for the fix. I have tested it on our end. > Could you please apply it? > > Thanks, > Masroor > > -----Original Message----- > From: Stefan Hajnoczi [mailto:ste...@gm...] > Sent: Thursday, March 04, 2010 2:37 PM > To: Masroor Vettuparambil > Cc: eth...@li...; Marty Connor; Sivakumar > Subramani; Ramkrishna Vepa; Stefan Hajnoczi > Subject: [PATCH] [vxge] Add stub vxge.c file so bin/vxge.usb can be > built > > The vxge driver code is split over several files, including vxge_main.c. > This causes the build system and ROM-o-matic to see the driver as > "vxge_main". > > This patch adds a stub vxge.c which takes up no space but gives the > driver its proper name, "vxge". > > Signed-off-by: Stefan Hajnoczi<ste...@gm...> > --- > src/drivers/net/vxge/vxge.c | 18 ++++++++++++++++++ > src/drivers/net/vxge/vxge_main.c | 9 +++++---- > 2 files changed, 23 insertions(+), 4 deletions(-) > create mode 100644 src/drivers/net/vxge/vxge.c > > diff --git a/src/drivers/net/vxge/vxge.c b/src/drivers/net/vxge/vxge.c > new file mode 100644 > index 0000000..a24932e > --- /dev/null > +++ b/src/drivers/net/vxge/vxge.c > @@ -0,0 +1,18 @@ > +/** @file Stub file for vxge driver > + * > + * This file drags in the rest of the driver for Neterion Inc's X3100 > Series > + * 10GbE PCIe I/O Virtualized Server Adapter, allowing the driver to be > built > + * as "vxge" even though the code is in vxge_* named files. > + */ > + > +FILE_LICENCE(GPL2_OR_LATER); > + > +#include<gpxe/pci.h> > + > +REQUIRE_OBJECT(vxge_main); > + > +/** vxge PCI IDs for util/parserom.pl which are put into bin/NIC */ > +static struct pci_device_id vxge_nics[] __unused = { > + /* If you change this, also adjust vxge_main_nics[] in > vxge_main.c */ > + PCI_ROM(0x17d5, 0x5833, "vxge-x3100", "Neterion X3100 Series", > 0), > +}; > diff --git a/src/drivers/net/vxge/vxge_main.c > b/src/drivers/net/vxge/vxge_main.c > index f69cdd2..8f5ba47 100644 > --- a/src/drivers/net/vxge/vxge_main.c > +++ b/src/drivers/net/vxge/vxge_main.c > @@ -712,13 +712,14 @@ static struct net_device_operations > vxge_operations = { > .irq = vxge_irq, > }; > > -static struct pci_device_id vxge_nics[] = { > - PCI_ROM(0x17d5, 0x5833, "vxge-x3100", "Neterion X3100 Series", > 0), > +static struct pci_device_id vxge_main_nics[] = { > + /* If you change this, also adjust vxge_nics[] in vxge.c */ > + PCI_ID(0x17d5, 0x5833, "vxge-x3100", "Neterion X3100 Series", > 0), > }; > > struct pci_driver vxge_driver __pci_driver = { > - .ids = vxge_nics, > - .id_count = (sizeof(vxge_nics) / sizeof(vxge_nics[0])), > + .ids = vxge_main_nics, > + .id_count = (sizeof(vxge_main_nics) / > sizeof(vxge_main_nics[0])), > .probe = vxge_probe, > .remove = vxge_remove, > }; |
From: <Matt_Domsch@Dell.com> - 2010-03-05 15:38:04
|
Thank you Stefan for tracking this down! I thought I was seeing things after our IRC conversation about it. :-) -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -----Original Message----- From: Marty Connor [mailto:md...@et...] Sent: Tuesday, March 02, 2010 9:14 PM To: Stefan Hajnoczi Cc: Etherboot General Discussion List; Etherboot Developers List; gpx...@et... Subject: Re: [Etherboot-developers] [gPXE-devel] [PATCH] [makefile] Disable ccache for embedded.o Wow. Nice debugging, Stefan. Seems like a nice improvement. Looks like something we should definitely apply, when you're comfortable with it. Hmm, I also just noticed that hardly anyone has joined gpxe-devel. I think a message to etherboot-developers is in order. Patches like this are too good to miss :) Hey! All you people on Etherboot-Developers, please join gpx...@et... (and gp...@et... if you haven't) >>>> http://etherboot.org/mailman/listinfo <<<< Don't miss out on quality conversation! Join today! :) / Marty / On 3/1/10 3:34 PM, Stefan Hajnoczi wrote: > Embedded image support uses .incbin in inline assembly to include binary > files. The file dependency is not spotted by ccache when deciding > whether or not to rebuild embedded.o. This results in builds that > contain an outdated version of the embedded image when ccache is used. > > Reported-by: Tim 'Shaggy' Bielawa <tbi...@ja...> > Reported-by: Matt Domsch <Mat...@de...> > Signed-off-by: Stefan Hajnoczi <ste...@gm...> > --- > src/Makefile.housekeeping | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping > index 1f5e115..8ba7e44 100644 > --- a/src/Makefile.housekeeping > +++ b/src/Makefile.housekeeping > @@ -511,6 +511,13 @@ EMBED_ALL := $(foreach i,$(call seq,1,$(words $(EMBEDDED_FILES))),\ > \"$(notdir $(word $(i),$(EMBEDDED_FILES)))\" )) > > $(BIN)/embedded.o : $(EMBEDDED_FILES) $(EMBEDDED_LIST) > + > +# This file uses .incbin inline assembly to include a binary file. > +# Unfortunately ccache does not detect this dependency and caches builds even > +# when the binary file has changed. > +# > +$(BIN)/embedded.o : override CC := env CCACHE_DISABLE=1 $(CC) > + > CFLAGS_embedded = -DEMBED_ALL="$(EMBED_ALL)" > > # Generate the NIC file from the parsed source files. The NIC file is ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Etherboot-developers mailing list Eth...@li... https://lists.sourceforge.net/lists/listinfo/etherboot-developers |
From: Masroor V. <Mas...@ne...> - 2010-03-05 10:28:29
|
Hi Stefan, Thanks for the fix. I have tested it on our end. Could you please apply it? Thanks, Masroor -----Original Message----- From: Stefan Hajnoczi [mailto:ste...@gm...] Sent: Thursday, March 04, 2010 2:37 PM To: Masroor Vettuparambil Cc: eth...@li...; Marty Connor; Sivakumar Subramani; Ramkrishna Vepa; Stefan Hajnoczi Subject: [PATCH] [vxge] Add stub vxge.c file so bin/vxge.usb can be built The vxge driver code is split over several files, including vxge_main.c. This causes the build system and ROM-o-matic to see the driver as "vxge_main". This patch adds a stub vxge.c which takes up no space but gives the driver its proper name, "vxge". Signed-off-by: Stefan Hajnoczi <ste...@gm...> --- src/drivers/net/vxge/vxge.c | 18 ++++++++++++++++++ src/drivers/net/vxge/vxge_main.c | 9 +++++---- 2 files changed, 23 insertions(+), 4 deletions(-) create mode 100644 src/drivers/net/vxge/vxge.c diff --git a/src/drivers/net/vxge/vxge.c b/src/drivers/net/vxge/vxge.c new file mode 100644 index 0000000..a24932e --- /dev/null +++ b/src/drivers/net/vxge/vxge.c @@ -0,0 +1,18 @@ +/** @file Stub file for vxge driver + * + * This file drags in the rest of the driver for Neterion Inc's X3100 Series + * 10GbE PCIe I/O Virtualized Server Adapter, allowing the driver to be built + * as "vxge" even though the code is in vxge_* named files. + */ + +FILE_LICENCE(GPL2_OR_LATER); + +#include <gpxe/pci.h> + +REQUIRE_OBJECT(vxge_main); + +/** vxge PCI IDs for util/parserom.pl which are put into bin/NIC */ +static struct pci_device_id vxge_nics[] __unused = { + /* If you change this, also adjust vxge_main_nics[] in vxge_main.c */ + PCI_ROM(0x17d5, 0x5833, "vxge-x3100", "Neterion X3100 Series", 0), +}; diff --git a/src/drivers/net/vxge/vxge_main.c b/src/drivers/net/vxge/vxge_main.c index f69cdd2..8f5ba47 100644 --- a/src/drivers/net/vxge/vxge_main.c +++ b/src/drivers/net/vxge/vxge_main.c @@ -712,13 +712,14 @@ static struct net_device_operations vxge_operations = { .irq = vxge_irq, }; -static struct pci_device_id vxge_nics[] = { - PCI_ROM(0x17d5, 0x5833, "vxge-x3100", "Neterion X3100 Series", 0), +static struct pci_device_id vxge_main_nics[] = { + /* If you change this, also adjust vxge_nics[] in vxge.c */ + PCI_ID(0x17d5, 0x5833, "vxge-x3100", "Neterion X3100 Series", 0), }; struct pci_driver vxge_driver __pci_driver = { - .ids = vxge_nics, - .id_count = (sizeof(vxge_nics) / sizeof(vxge_nics[0])), + .ids = vxge_main_nics, + .id_count = (sizeof(vxge_main_nics) / sizeof(vxge_main_nics[0])), .probe = vxge_probe, .remove = vxge_remove, }; -- 1.6.6.1 |
From: Stefan H. <ste...@gm...> - 2010-03-04 09:06:44
|
The vxge driver code is split over several files, including vxge_main.c. This causes the build system and ROM-o-matic to see the driver as "vxge_main". This patch adds a stub vxge.c which takes up no space but gives the driver its proper name, "vxge". Signed-off-by: Stefan Hajnoczi <ste...@gm...> --- src/drivers/net/vxge/vxge.c | 18 ++++++++++++++++++ src/drivers/net/vxge/vxge_main.c | 9 +++++---- 2 files changed, 23 insertions(+), 4 deletions(-) create mode 100644 src/drivers/net/vxge/vxge.c diff --git a/src/drivers/net/vxge/vxge.c b/src/drivers/net/vxge/vxge.c new file mode 100644 index 0000000..a24932e --- /dev/null +++ b/src/drivers/net/vxge/vxge.c @@ -0,0 +1,18 @@ +/** @file Stub file for vxge driver + * + * This file drags in the rest of the driver for Neterion Inc's X3100 Series + * 10GbE PCIe I/O Virtualized Server Adapter, allowing the driver to be built + * as "vxge" even though the code is in vxge_* named files. + */ + +FILE_LICENCE(GPL2_OR_LATER); + +#include <gpxe/pci.h> + +REQUIRE_OBJECT(vxge_main); + +/** vxge PCI IDs for util/parserom.pl which are put into bin/NIC */ +static struct pci_device_id vxge_nics[] __unused = { + /* If you change this, also adjust vxge_main_nics[] in vxge_main.c */ + PCI_ROM(0x17d5, 0x5833, "vxge-x3100", "Neterion X3100 Series", 0), +}; diff --git a/src/drivers/net/vxge/vxge_main.c b/src/drivers/net/vxge/vxge_main.c index f69cdd2..8f5ba47 100644 --- a/src/drivers/net/vxge/vxge_main.c +++ b/src/drivers/net/vxge/vxge_main.c @@ -712,13 +712,14 @@ static struct net_device_operations vxge_operations = { .irq = vxge_irq, }; -static struct pci_device_id vxge_nics[] = { - PCI_ROM(0x17d5, 0x5833, "vxge-x3100", "Neterion X3100 Series", 0), +static struct pci_device_id vxge_main_nics[] = { + /* If you change this, also adjust vxge_nics[] in vxge.c */ + PCI_ID(0x17d5, 0x5833, "vxge-x3100", "Neterion X3100 Series", 0), }; struct pci_driver vxge_driver __pci_driver = { - .ids = vxge_nics, - .id_count = (sizeof(vxge_nics) / sizeof(vxge_nics[0])), + .ids = vxge_main_nics, + .id_count = (sizeof(vxge_main_nics) / sizeof(vxge_main_nics[0])), .probe = vxge_probe, .remove = vxge_remove, }; -- 1.6.6.1 |
From: Stefan H. <ste...@gm...> - 2010-03-04 09:04:13
|
On Tue, Mar 2, 2010 at 5:49 AM, Masroor Vettuparambil <Mas...@ne...> wrote: > The rom-o-matic.net list the NIC type as vxge_main. Could you please > change it to just vxge? It is not possible to manually edit the list on ROM-o-matic.net because it is auto-generated. The simplest solution is to rename vxge_main.{c,h} to vxge.{c,h}. If you really don't want to do this because it no longer corresponds with the vxge driver code on other platforms, you can use a stub vxge.c file that makes the build system and ROM-o-matic see the driver as "vxge". I have sent a patch which does this as a follow-up to this email. Please let me know which approach you want to take. Stefan |
From: Marty C. <md...@et...> - 2010-03-03 04:13:52
|
Wow. Nice debugging, Stefan. Seems like a nice improvement. Looks like something we should definitely apply, when you're comfortable with it. Hmm, I also just noticed that hardly anyone has joined gpxe-devel. I think a message to etherboot-developers is in order. Patches like this are too good to miss :) Hey! All you people on Etherboot-Developers, please join gpx...@et... (and gp...@et... if you haven't) >>>> http://etherboot.org/mailman/listinfo <<<< Don't miss out on quality conversation! Join today! :) / Marty / On 3/1/10 3:34 PM, Stefan Hajnoczi wrote: > Embedded image support uses .incbin in inline assembly to include binary > files. The file dependency is not spotted by ccache when deciding > whether or not to rebuild embedded.o. This results in builds that > contain an outdated version of the embedded image when ccache is used. > > Reported-by: Tim 'Shaggy' Bielawa <tbi...@ja...> > Reported-by: Matt Domsch <Mat...@de...> > Signed-off-by: Stefan Hajnoczi <ste...@gm...> > --- > src/Makefile.housekeeping | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/src/Makefile.housekeeping b/src/Makefile.housekeeping > index 1f5e115..8ba7e44 100644 > --- a/src/Makefile.housekeeping > +++ b/src/Makefile.housekeeping > @@ -511,6 +511,13 @@ EMBED_ALL := $(foreach i,$(call seq,1,$(words $(EMBEDDED_FILES))),\ > \"$(notdir $(word $(i),$(EMBEDDED_FILES)))\" )) > > $(BIN)/embedded.o : $(EMBEDDED_FILES) $(EMBEDDED_LIST) > + > +# This file uses .incbin inline assembly to include a binary file. > +# Unfortunately ccache does not detect this dependency and caches builds even > +# when the binary file has changed. > +# > +$(BIN)/embedded.o : override CC := env CCACHE_DISABLE=1 $(CC) > + > CFLAGS_embedded = -DEMBED_ALL="$(EMBED_ALL)" > > # Generate the NIC file from the parsed source files. The NIC file is |
From: Masroor V. <Mas...@ne...> - 2010-03-02 05:54:01
|
Thanks, Stefan. The rom-o-matic.net list the NIC type as vxge_main. Could you please change it to just vxge? -Masroor -----Original Message----- From: Stefan Hajnoczi [mailto:ste...@gm...] Sent: Saturday, February 27, 2010 6:13 PM To: Masroor Vettuparambil Cc: eth...@li...; Marty Connor; Sivakumar Subramani; Ramkrishna Vepa Subject: Re: [Etherboot-developers] [PATCH 6/6] vxge driver submission The vxge driver has been merged. Thank you for contributing! Stefan |