January 2015 - kernelnewbies@kernelnewbies.org

Submitted a first patch and no reply
by shirish gajera Jan. 9, 2015

Jan. 9, 2015

Hi, I have submitted my first patch on 12/30/2014 and I have not received any reply for next step like error or merge ect. I send the email to person that get_maintainer.pl script tells me to send. Please guide whom should I reached for this. Below is the email --------- This patch fixes the checkpatch.pl warning: WARNING: Single statement macros should not use a do {} while (0) loop I have added single statement in curly braces, because it was giving me "WARNING: macros should not use a trailing semicolon". Signed-off-by: Shirish Gajera <gajerashirish(a)gmail.com> --- drivers/staging/skein/skein_block.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/skein/skein_block.c b/drivers/staging/skein/skein_block.c index 66261ab..5f46cd6 100644 --- a/drivers/staging/skein/skein_block.c +++ b/drivers/staging/skein/skein_block.c @@ -82,10 +82,10 @@ do { \ } while (0) #else /* looping version */ -#define R256(p0, p1, p2, p3, ROT, r_num) \ -do { \ - ROUND256(p0, p1, p2, p3, ROT, r_num); \ -} while (0) +#define R256(p0, p1, p2, p3, ROT, r_num) \ +{ \ + ROUND256(p0, p1, p2, p3, ROT, r_num); \ +} #define I256(R) \ do { \ --------------------------- Thanks, Shirish

4 7

Query regarding a IIO consumer touchscreen driver
by Sanchayan Maity Jan. 9, 2015

Jan. 9, 2015

Hello, I have been working on a IIO consumer touchscreen driver. On one of our Vybrid modules we use the ADC channels for the touchscreen. I ported an earlier driver in the 3.0 kernel done by my colleague to the recent 3.18/19 kernel to use the IIO based consumer interface. The touchscreen driver is here http://git.toradex.com/cgit/linux-toradex.git/tree/drivers/input/touchscree… The ADC driver with which it interacts is here http://git.toradex.com/cgit/linux-toradex.git/tree/drivers/iio/adc/vf610_ad… Currently, this works in a limited capaicty I would say. One of the problems I have with this driver is that when this driver is used I can't get valid readings for any of the other ADC channels by using something like "cat". I believe this is because of the fact that the workqueue runs a while loop every 10ms and reads the channels. This clearly does not play well with reading of other channels and results in random reads on trying to read other channels, for example the temperature channel. The exact reason I have not figured out here. I was thinking may be a device lock would be required, but, that doesn't help. The workqueue function http://git.toradex.com/cgit/linux-toradex.git/tree/drivers/input/touchscree… The primary read raw function http://git.toradex.com/cgit/linux-toradex.git/tree/drivers/iio/adc/vf610_ad… I was thinking this would need a better design than what has been done? Can someone give some suggestions as what would be the right design/architecture here. I was thinking if setting up a IIO ring buffer, pushing the readings to it and then reading from the touchscreen driver would work. One of the aims is also to make it clean enough for eventual submission to the mainline. Thanks & Regards, Sanchayan Maity.

2 1

Fwd: Question about kernel interfaces
by Siddhartha De Jan. 9, 2015

Jan. 9, 2015

Looks like the last message bounced ... Thanks , Kernel Newbie :) ---------- Forwarded message ---------- From: Siddhartha De <siddhartha.de87(a)gmail.com> Date: Fri, Jan 9, 2015 at 5:50 PM Subject: Fwd: Question about kernel interfaces To: linux-kernel <linux-kernel(a)vger.kernel.org>, Siddhartha De <siddhartha.de87(a)gmail.com>, kernelnewbies(a)kernelnewbies.org Hi , Dear Kernel Newbies , I have had some discussions regarding this on the IRC but I thought it would be a better idea to post it to the mailing list as well .... just in case someone came up with any ideas/comments/suggestions later .... PS :- I am marking a copy to the main linux-kernel list so that any discussions automatically gets forwarded there ... Thanks , Kernel Newbie :) ---------- Forwarded message ---------- From: Siddhartha De <siddhartha.de87(a)gmail.com> Date: Fri, Jan 9, 2015 at 5:18 PM Subject: Re: Question about kernel interfaces To: One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk> Cc: linux-kernel <linux-kernel(a)vger.kernel.org> Hi , Thanks for your reply . Really appreciate your taking time out to answer this ... 1> > Are all drivers in future required to expose interfaces in sysfs ? > Only if they need one (some will appear automatically as you enable power management and the like). Just wanted to point out something :- Quoting from makelinux website :- http://www.makelinux.net/books/lkd2/ch17lev1sec8 "The sysfs filesystem is currently the place for implementing functionality previously reserved for ioctl() calls on device nodes or the procfs filesystem. These days, the chic thing to do is implement such functionality as sysfs attributes in the appropriate directory. For example, instead of a new ioctl() on a device node, add a sysfs attribute in the driver's sysfs directory. Such an approach avoids the type-unsafe use of obscure ioctl() arguments and the haphazard mess of /proc. " Quoting from the busybox mailing list archives :- Hi vda, all, ISTR that sysfs was the long-term plan of the kernel folks and that they mean to completely(?) drop ioctl support. In what timeframe should we migrate to "pure" sysfs and drop using any ioctls (if a sysfs interface exists)? cheers, Bernhard Quote from livejournal http://zaitcev.livejournal.com/84788.html sysfs is the new ioctl With all these spread all over the net , any newbie like myself is bound to get confused ... add to that I just saw some old mails from Linus where he blasts the ioctl way of doing things ( http://yarchive.net/comp/linux/ioctl.html ) :) 2> It's not entirely impossible to make syscalls remotable. It's been done to some extent at least two ways. Read up on plan 9 (which did try and take Unix much more networked and within the classic tradition of Unix as a small clean OS), Thanks for the advice , I did read up a bit on Plan 9 , but from what I understood it was trying to abstract the network to the user ... a bit different from what my confusion is .... but a great resource nevertheless 3> >I'm not sure I'd pick Java for this either - Java is very weak in this area as it tends to expose notions of locality and what is and isn't remote when doing method invocations. Languages like smalltalk on the other hand got this right many years before. Yeah ... the reason I mentioned Java is because it represents a typical high level language commonly used by today's programmers ... the problem with all these languages is that while they do a fine job when writing web based applications they really make it difficult to access low level system calls ( for eg talking to the driver and stuff ) . Moreover when a library is written for say Linux or Windows the library becomes tied to that particular language ( the one it is written in ) ... for eg let us say we write a new library in C for playing mp3 's in Linux ... if we are to write a user space program and want to access the library 's functionality we have to write the userspace program in C ... if we write it in any other language ( say Java ) we have to use other methods like Java Native Interface ( JNI ... or more recently JNA ) to access this ... not a good way . What I am saying is let us expose the library over http/any other network protocol ... if any other language needs to access the library's functionality it simply makes a request like :- http://localhost:7000/libmp3/foo?arg1=something&arg2=something This way we avoid a lot of rework since once a library is written it's functionality is exposed to all languages ( Java / PHP / Python ) . Taking this idea further , could we also expose driver IOCTL's over the network ? For eg to open the cd rom drive we would be calling the following url :- (assuming device is /dev/cdrom ) http://localhost:7000/IOCTL/IOCTL_EJECT?device=/dev/cdrom The listener program ( our interpreter listening on port 7000 ) would be taking this url call and doing the actual IOCTL call file_handle= open ( /dev/cdrom ) call_IOCTL ( file_handle,IOCTL_EJECT, &some_structure ) The idea of exposing all these interfaces as url's is not to make them accessible over the network ( although this could be a possibility ...) but simply to make them accessible from any user space program in a language neutral way ... Thanks Kernel Newbie :) On Thu, Jan 8, 2015 at 7:18 PM, One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk> wrote: >> Is sysfs 'supposed' to be a read only where various kernel parameters >> are exposed to be read ? Or are they 'supposed' to be writable too ? > > You can create either > >> Are all drivers in future required to expose interfaces in sysfs ? > > Only if they need one (some will appear automatically as you enable power > management and the like). > >> If the answer to the above is true , then would we be really requiring >> IOCTL calls at all anymore ... because all that we would need to do to >> make a driver do something is to change values in some of the files in >> sysfs ... for eg to call a ioctl called DO_SOMETHING on driver D1 we >> would be doing : >> >> echo 1> /sysfs/D1/IOCTLS/DO_SOMETHING ( or something like that ... :) ) > > Try implementing a few this way and you'll discover you can't. ioctls > happen on file handles which are tied to instances of an object not to > the driver. ioctl also allows read/write pairs so can be serializing and > sequenced in a way sysfs can't. > >> Are there any plans of exposing the kernel api ( that is syscalls and >> libc ) as sysfs files ... for eg >> >> echo 1> /sysfs/libc/get_system_time >> cat /sysfs/libc/results/system_time > > Time is an example where you could implement it via sysfs. It's an > unusual case in that its global and stateless. > >> Would it be a good idea to do this ? > > No, probably not. > >> How about exposing core system calls , libc and any new libraries over >> http/over the network ? This would make calling ioctls and really low >> level stuff from high level languages like Java a trivial process . >> For eg right now if I wanted to call some function say foo () in >> library my_library.so in Java I would have to take the JNI/JNA route >> ... doable but not exactly 'easy' ( same for other high level >> languages ) ... whereas in the new way all I would have to do is send >> a request to say :- >> http://localhost:7000/my_library/foo?arg1=something,arg2=something >> ( Just wanted a frank discussion on this idea .... ) > > Except that you've also got to transfer the data and the authentication > back and forth. You need much more than sysfs for this, you need some way > to pass messages securely, and to do work on a remote node on your > behalf. You need some way to locate a resource. > > It's not entirely impossible to make syscalls remotable. It's been done to > some extent at least two ways. Read up on plan 9 (which did try and take > Unix much more networked and within the classic tradition of Unix as a > small clean OS), and perhaps also on MOSIX, which took a very different > approach to running on a cluster of boxes as one instance. Another odd > example to look at is Minix. Minix treats all syscalls internally as > messages between user processes and services like the file system. Minix > never really made use of it, but it does mean its much easier to do > remote syscall models in Minix than Linux. (in part I suspect this comes > from Tanenbaum's Amoeba and similar work). > > I'm not sure I'd pick Java for this either - Java is very weak in this > area as it tends to expose notions of locality and what is and isn't > remote when doing method invocations. Languages like smalltalk on the > other hand got this right many years before. > > Alan > On Wednesday Jan 7th Siddhartha De (siddhartha.de87(a)gmail.com ) wrote :- I have already asked this question on the kernelnewbies IRC but I wanted a bit of feedback from the Linux gurus ... Is sysfs 'supposed' to be a read only where various kernel parameters are exposed to be read ? Or are they 'supposed' to be writable too ? Are all drivers in future required to expose interfaces in sysfs ? If the answer to the above is true , then would we be really requiring IOCTL calls at all anymore ... because all that we would need to do to make a driver do something is to change values in some of the files in sysfs ... for eg to call a ioctl called DO_SOMETHING on driver D1 we would be doing : echo 1> /sysfs/D1/IOCTLS/DO_SOMETHING ( or something like that ... :) ) Are there any plans of exposing the kernel api ( that is syscalls and libc ) as sysfs files ... for eg echo 1> /sysfs/libc/get_system_time cat /sysfs/libc/results/system_time Would it be a good idea to do this ? How about exposing core system calls , libc and any new libraries over http/over the network ? This would make calling ioctls and really low level stuff from high level languages like Java a trivial process . For eg right now if I wanted to call some function say foo () in library my_library.so in Java I would have to take the JNI/JNA route ... doable but not exactly 'easy' ( same for other high level languages ) ... whereas in the new way all I would have to do is send a request to say :- http://localhost:7000/my_library/foo?arg1=something,arg2=something ( Just wanted a frank discussion on this idea .... ) Thanking you in anticipation , Yours sincerely , Kernel newbie

2 1

Fwd: Question about kernel interfaces
by Siddhartha De Jan. 9, 2015

Jan. 9, 2015

Hi , Dear Kernel Newbies , I have had some discussions regarding this on the IRC but I thought it would be a better idea to post it to the mailing list as well .... just in case someone came up with any ideas/comments/suggestions later .... PS :- I am marking a copy to the main linux-kernel list so that any discussions automatically gets forwarded there ... Thanks , Kernel Newbie :) ---------- Forwarded message ---------- From: Siddhartha De <siddhartha.de87(a)gmail.com> Date: Fri, Jan 9, 2015 at 5:18 PM Subject: Re: Question about kernel interfaces To: One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk> Cc: linux-kernel <linux-kernel(a)vger.kernel.org> Hi , Thanks for your reply . Really appreciate your taking time out to answer this ... 1> > Are all drivers in future required to expose interfaces in sysfs ? > Only if they need one (some will appear automatically as you enable power management and the like). Just wanted to point out something :- Quoting from makelinux website :- http://www.makelinux.net/books/lkd2/ch17lev1sec8 "The sysfs filesystem is currently the place for implementing functionality previously reserved for ioctl() calls on device nodes or the procfs filesystem. These days, the chic thing to do is implement such functionality as sysfs attributes in the appropriate directory. For example, instead of a new ioctl() on a device node, add a sysfs attribute in the driver's sysfs directory. Such an approach avoids the type-unsafe use of obscure ioctl() arguments and the haphazard mess of /proc. " Quoting from the busybox mailing list archives :- Hi vda, all, ISTR that sysfs was the long-term plan of the kernel folks and that they mean to completely(?) drop ioctl support. In what timeframe should we migrate to "pure" sysfs and drop using any ioctls (if a sysfs interface exists)? cheers, Bernhard Quote from livejournal http://zaitcev.livejournal.com/84788.html sysfs is the new ioctl With all these spread all over the net , any newbie like myself is bound to get confused ... add to that I just saw some old mails from Linus where he blasts the ioctl way of doing things ( http://yarchive.net/comp/linux/ioctl.html ) :) 2> It's not entirely impossible to make syscalls remotable. It's been done to some extent at least two ways. Read up on plan 9 (which did try and take Unix much more networked and within the classic tradition of Unix as a small clean OS), Thanks for the advice , I did read up a bit on Plan 9 , but from what I understood it was trying to abstract the network to the user ... a bit different from what my confusion is .... but a great resource nevertheless 3> >I'm not sure I'd pick Java for this either - Java is very weak in this area as it tends to expose notions of locality and what is and isn't remote when doing method invocations. Languages like smalltalk on the other hand got this right many years before. Yeah ... the reason I mentioned Java is because it represents a typical high level language commonly used by today's programmers ... the problem with all these languages is that while they do a fine job when writing web based applications they really make it difficult to access low level system calls ( for eg talking to the driver and stuff ) . Moreover when a library is written for say Linux or Windows the library becomes tied to that particular language ( the one it is written in ) ... for eg let us say we write a new library in C for playing mp3 's in Linux ... if we are to write a user space program and want to access the library 's functionality we have to write the userspace program in C ... if we write it in any other language ( say Java ) we have to use other methods like Java Native Interface ( JNI ... or more recently JNA ) to access this ... not a good way . What I am saying is let us expose the library over http/any other network protocol ... if any other language needs to access the library's functionality it simply makes a request like :- http://localhost:7000/libmp3/foo?arg1=something&arg2=something This way we avoid a lot of rework since once a library is written it's functionality is exposed to all languages ( Java / PHP / Python ) . Taking this idea further , could we also expose driver IOCTL's over the network ? For eg to open the cd rom drive we would be calling the following url :- (assuming device is /dev/cdrom ) http://localhost:7000/IOCTL/IOCTL_EJECT?device=/dev/cdrom The listener program ( our interpreter listening on port 7000 ) would be taking this url call and doing the actual IOCTL call file_handle= open ( /dev/cdrom ) call_IOCTL ( file_handle,IOCTL_EJECT, &some_structure ) The idea of exposing all these interfaces as url's is not to make them accessible over the network ( although this could be a possibility ...) but simply to make them accessible from any user space program in a language neutral way ... Thanks Kernel Newbie :) On Thu, Jan 8, 2015 at 7:18 PM, One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk> wrote: >> Is sysfs 'supposed' to be a read only where various kernel parameters >> are exposed to be read ? Or are they 'supposed' to be writable too ? > > You can create either > >> Are all drivers in future required to expose interfaces in sysfs ? > > Only if they need one (some will appear automatically as you enable power > management and the like). > >> If the answer to the above is true , then would we be really requiring >> IOCTL calls at all anymore ... because all that we would need to do to >> make a driver do something is to change values in some of the files in >> sysfs ... for eg to call a ioctl called DO_SOMETHING on driver D1 we >> would be doing : >> >> echo 1> /sysfs/D1/IOCTLS/DO_SOMETHING ( or something like that ... :) ) > > Try implementing a few this way and you'll discover you can't. ioctls > happen on file handles which are tied to instances of an object not to > the driver. ioctl also allows read/write pairs so can be serializing and > sequenced in a way sysfs can't. > >> Are there any plans of exposing the kernel api ( that is syscalls and >> libc ) as sysfs files ... for eg >> >> echo 1> /sysfs/libc/get_system_time >> cat /sysfs/libc/results/system_time > > Time is an example where you could implement it via sysfs. It's an > unusual case in that its global and stateless. > >> Would it be a good idea to do this ? > > No, probably not. > >> How about exposing core system calls , libc and any new libraries over >> http/over the network ? This would make calling ioctls and really low >> level stuff from high level languages like Java a trivial process . >> For eg right now if I wanted to call some function say foo () in >> library my_library.so in Java I would have to take the JNI/JNA route >> ... doable but not exactly 'easy' ( same for other high level >> languages ) ... whereas in the new way all I would have to do is send >> a request to say :- >> http://localhost:7000/my_library/foo?arg1=something,arg2=something >> ( Just wanted a frank discussion on this idea .... ) > > Except that you've also got to transfer the data and the authentication > back and forth. You need much more than sysfs for this, you need some way > to pass messages securely, and to do work on a remote node on your > behalf. You need some way to locate a resource. > > It's not entirely impossible to make syscalls remotable. It's been done to > some extent at least two ways. Read up on plan 9 (which did try and take > Unix much more networked and within the classic tradition of Unix as a > small clean OS), and perhaps also on MOSIX, which took a very different > approach to running on a cluster of boxes as one instance. Another odd > example to look at is Minix. Minix treats all syscalls internally as > messages between user processes and services like the file system. Minix > never really made use of it, but it does mean its much easier to do > remote syscall models in Minix than Linux. (in part I suspect this comes > from Tanenbaum's Amoeba and similar work). > > I'm not sure I'd pick Java for this either - Java is very weak in this > area as it tends to expose notions of locality and what is and isn't > remote when doing method invocations. Languages like smalltalk on the > other hand got this right many years before. > > Alan > On Wednesday Jan 7th Siddhartha De (siddhartha.de87(a)gmail.com ) wrote :- I have already asked this question on the kernelnewbies IRC but I wanted a bit of feedback from the Linux gurus ... Is sysfs 'supposed' to be a read only where various kernel parameters are exposed to be read ? Or are they 'supposed' to be writable too ? Are all drivers in future required to expose interfaces in sysfs ? If the answer to the above is true , then would we be really requiring IOCTL calls at all anymore ... because all that we would need to do to make a driver do something is to change values in some of the files in sysfs ... for eg to call a ioctl called DO_SOMETHING on driver D1 we would be doing : echo 1> /sysfs/D1/IOCTLS/DO_SOMETHING ( or something like that ... :) ) Are there any plans of exposing the kernel api ( that is syscalls and libc ) as sysfs files ... for eg echo 1> /sysfs/libc/get_system_time cat /sysfs/libc/results/system_time Would it be a good idea to do this ? How about exposing core system calls , libc and any new libraries over http/over the network ? This would make calling ioctls and really low level stuff from high level languages like Java a trivial process . For eg right now if I wanted to call some function say foo () in library my_library.so in Java I would have to take the JNI/JNA route ... doable but not exactly 'easy' ( same for other high level languages ) ... whereas in the new way all I would have to do is send a request to say :- http://localhost:7000/my_library/foo?arg1=something,arg2=something ( Just wanted a frank discussion on this idea .... ) Thanking you in anticipation , Yours sincerely , Kernel newbie

1 0

Paging - can i know the last owner(pid) of a given page?
by manty kuma Jan. 9, 2015

Jan. 9, 2015

Dear friends, I have a very simple question related to pages. Suppose, I have a kernel virtual address. Can I know which is the process that last used this address? Probably we might need to look at the members of the page strucre which the virtual address is part of. Any relevant information will be very helpful. PS: I have crash tool to debug the issue. Regards, Manty

3 2

PCIe recovery mechanism
by Avinash Patil Jan. 9, 2015

Jan. 9, 2015

Hello, I was wondering if there is any way to recover from FW crash in case of WLAN PCie cards- say we power off card and power on. This would enable hotplug to detect it again and driver's probe routine would do redownload of FW and device is alive again. 1. I went through PCI bus driver sources and came across pci_set_power_state which can be used to set PCI power state to D0-D3hot/D3cold. Suppose we set power state to D3Cold, I dont think dev pointer would be valid again to set to D0. 2. Another idea is something similar to PCI rescan operation via sysfs(echo 1 > /sys/bus/pci/rescan). I am not entirely sure though if this can be applied to single device as this involves scanning all devices on PCI bus. Any help appreciated! Thanks, Avinash

2 1

ternary vs double exclamation
by Vinícius Tinti Jan. 8, 2015

Jan. 8, 2015

Hi, I was looking the kernel source code and there are a lot of places in which either "(expression) ? 1 : 0" or "(expression) ? 0 : 1" appear. As fair as I can tell both can be replaced by "!!expression" and "!expression". Moreover there it seems that using "!!" does not add a "nopl" instruction at the end of the call. Does anybody knows why? Anyway. Wouldn't be nice if kernel provides something like "boolean(x)" macro and "inv_boolean(x)" to do this operations? #ifdef MOD_IF int mod_if(int x) { return (x == 0) ? 0 : 1; } #endif #ifdef MOD_X int mod_x(int x) { return !!x; } #endif 0000000000000000 <mod_if>: 0: 31 c0 xor %eax,%eax 2: 85 ff test %edi,%edi 4: 0f 95 c0 setne %al 7: c3 retq 8: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) f: 00 0000000000000010 <mod_x>: 10: 31 c0 xor %eax,%eax 12: 85 ff test %edi,%edi 14: 0f 95 c0 setne %al 17: c3 retq Regards, Vinícius -- Simplicity is the ultimate sophistication

5 12

catch exit status of daemon
by Yash Jain Jan. 7, 2015

Jan. 7, 2015

Hello All, I have one dumb question, I wanted to write a process which monitors the exit status of the daemon, The Main process would fork a service, which would internally fork a child and , exit from the process. If main process wants to query the status of the daemon, how it can be achived. For ex : Process A would call a syslog service, which would internally fork a child, daemon it and exit, so if process A wants to wait for the syslog process, is it possible. Thanks in advance Regards, Yash.

7 7

realmode _WAKEUP
by Alexander Kuleshov Jan. 7, 2015

Jan. 7, 2015

Hello all, There is following definition at arch/x86/realmode/rm/Makefile: KBUILD_CFLAGS := $(LINUXINCLUDE) $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \ -I$(srctree)/arch/x86/boot Is it used now? I'm asking because _WAKEUP definition everywhere undefined in the code. Thank you.

2 7

Re: realmode _WAKEUP
by Alexander Kuleshov Jan. 7, 2015

Jan. 7, 2015

Seems that finally i got point of this. Thank you Paul for the help. 8 янв. 2015 г. 1:10 пользователь kuleshovmail(a)gmail.com написал: 8 янв. 2015 г. 0:57 пользователь "Paul Bolle" <pebolle(a)tiscali.nl> написал: > > On Wed, 2015-01-07 at 23:59 +0600, Alexander Kuleshov wrote: > > Yes i saw video-*.c files, but i can't understand how compilation of > > these video-*.c files depends on _WAKEUP macro... > > > > For example if'd remove -D_WAKEUP, i get errors during realmode.elf linking: > > > > arch/x86/realmode/rm/video-vga.o: In function `vga_probe': > > /home/alex/dev/linux/arch/x86/realmode/rm/../../boot/video-vga.c:259: > > undefined reference to `boot_params' > > > > As you wrote there are many #ifndef/#endif directives, but why there > > _WAKEUP is undefined everytime, but we pass it from command line with > > -D_WAKEUP? > > Because these file also get compiled via arch/x86/boot/Makefile? Ie, I > _guess_ _WAKEUP is needed to ensure the compile started from > arch/x86/realmode/rm/Makefile differs from the compile started from > arch/x86/boot/Makefile. But [...]/boot/Makefile is sufficiently > complicated for me to stop me from looking at it too long! > > You do realize that the Linux kernel is a treasure trove for people > wanting to know just how far make, gcc, etc can be pushed, don't you? > > > Paul Bolle > That's true

1 0