Re: CVS commit: src/usr.sbin/makefs
On Tue, May 24, 2011 at 11:01:42PM +0900, Izumi Tsutsui wrote: On Tue, May 24, 2011 at 09:52:18PM +0900, Izumi Tsutsui wrote: It looks mandatory to make makefs(8) handle partition maps for CD images. I'm not sure I understand exactly what you mean and why makefs is the right tool here. Postprocessing the image is fine I think the problem is that the final ISO9660 output including embeded MD boot fs and partition maps still has to be iso9660 compliant. There is no public space to store MD parameters for postprocessing in output image, ... Could the extra parameters be put into a file within the image? Then the postprocessing phase would have the required data. Or even in a separate file ! David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/dev
On Wed, 25 May 2011, Masao Uebayashi wrote: Module Name: src Committed By: uebayasi Date: Wed May 25 16:33:38 UTC 2011 Modified Files: src/sys/dev/bluetooth: bcsp.c bthub.c btuart.c src/sys/dev/ieee1394: fwdev.c fwmem.c fwohci.c Log Message: Declare cfdrivers using extern rather than including ioconf.h. surely the point of declaring a variable once in a header file is that it then cannot be accidentally declared differently elsewhere? is ioconf.h so onerous? (it is merely a list of cfdriver declarations) iain
Re: CVS commit: src/sys/dev
On Thu, May 26, 2011 at 2:09 AM, Iain Hibbert plu...@rya-online.net wrote: On Wed, 25 May 2011, Masao Uebayashi wrote: Module Name: src Committed By: uebayasi Date: Wed May 25 16:33:38 UTC 2011 Modified Files: src/sys/dev/bluetooth: bcsp.c bthub.c btuart.c src/sys/dev/ieee1394: fwdev.c fwmem.c fwohci.c Log Message: Declare cfdrivers using extern rather than including ioconf.h. surely the point of declaring a variable once in a header file is that it then cannot be accidentally declared differently elsewhere? is ioconf.h so onerous? (it is merely a list of cfdriver declarations) ioconf.h is not, but GCC is. I found 2 fwmem.o's signatures mismatch between 2 kernels; GENERIC and another doing only no ehci and include GENERIC. objdump -D shows: @@ -956,7 +956,7 @@ .ident: 0: 24 4e and$0x4e,%al 2: 65 gs - 3: 74 42 je 47 __func__.11035+0x11 + 3: 74 42 je 47 __func__.11034+0x11 5: 53 push %rbx 6: 44 24 00rex.R and$0x0,%al GCC definitely lacks care about reproducibility. So why s/include ioconf.h/extern/? Think it of a cosmetic change. ;) iain
Re: CVS commit: src/sys/dev
On Thu, 26 May 2011, Masao Uebayashi wrote: On Thu, May 26, 2011 at 2:09 AM, Iain Hibbert plu...@rya-online.net wrote: On Wed, 25 May 2011, Masao Uebayashi wrote: Module Name: src Committed By: uebayasi Date: Wed May 25 16:33:38 UTC 2011 Modified Files: src/sys/dev/bluetooth: bcsp.c bthub.c btuart.c src/sys/dev/ieee1394: fwdev.c fwmem.c fwohci.c Log Message: Declare cfdrivers using extern rather than including ioconf.h. surely the point of declaring a variable once in a header file is that it then cannot be accidentally declared differently elsewhere? is ioconf.h so onerous? (it is merely a list of cfdriver declarations) ioconf.h is not, but GCC is. I found 2 fwmem.o's signatures mismatch between 2 kernels; GENERIC and another doing only no ehci and include GENERIC. objdump -D shows: @@ -956,7 +956,7 @@ .ident: 0: 24 4e and$0x4e,%al 2: 65 gs - 3: 74 42 je 47 __func__.11035+0x11 + 3: 74 42 je 47 __func__.11034+0x11 5: 53 push %rbx 6: 44 24 00rex.R and$0x0,%al Hm, but I don't see a mismatch here though.. the actual bytes are the same, and that .ident section contains just the string $NetBSD$ ? iain
Re: CVS commit: src/sys/dev
On Thu, May 26, 2011 at 4:41 AM, David Laight da...@l8s.co.uk wrote: On Thu, May 26, 2011 at 02:33:38AM +0900, Masao Uebayashi wrote: Modified Files: ? ? ? src/sys/dev/bluetooth: bcsp.c bthub.c btuart.c ? ? ? src/sys/dev/ieee1394: fwdev.c fwmem.c fwohci.c Log Message: Declare cfdrivers using extern rather than including ioconf.h. surely the point of declaring a variable once in a header file is that it then cannot be accidentally declared differently elsewhere? is ioconf.h so onerous? (it is merely a list of cfdriver declarations) ioconf.h is not, but GCC is. I found 2 fwmem.o's signatures mismatch between 2 kernels; GENERIC and another doing only no ehci and include GENERIC. objdump -D shows: @@ -956,7 +956,7 @@ .ident: 0: 24 4e and $0x4e,%al 2: 65 gs - 3: 74 42 je 47 __func__.11035+0x11 + 3: 74 42 je 47 __func__.11034+0x11 5: 53 push %rbx 6: 44 24 00 rex.R and $0x0,%al GCC definitely lacks care about reproducibility. I don't think that you can expect the internal symbols generated by gcc to match when code is compiled in different contexts. Coming to consider what is a context..., why do these drivers have to include ioconf.h to know alll the other cfdriver decls? If these really need their own cfdriver decl, these unnecessarily widen contents, which is, if not a bug, confusing. Ultimately all (MI) drivers will become modules. Which means all objects will have to become bit-identical across kernels. Drivers including ioconf.h is doing something opposite. (So I'd withdraw a comment that GCC is onerous.) If you want to compare .o files that are built with different compilation options you really need to massage them somewhat first - or only compare some sections. David -- David Laight: da...@l8s.co.uk
