Re: [Haifux] My Modem, the Kernel and Me
On Sun, 23 Feb 2003 00:50:59 +0200 (IST) guy keren <[EMAIL PROTECTED]> wrote: > . lot's of good and interesting reading snipped . > this possibly stems from the open-sourceness stand of the kernel people - > they want drivers to be open-source and placed inside the kernel. The kernel developers obviously discriminate closed source drivers in any possible way. Cons: It lowers the ammount of drivers available to Linux. ...At least if you are willing to believe that under a "binary friendly" environment, the hardware vendors would rush to build/test/release excelent binary drivers for us. (personally it's hard for me to imagine it happening). Pros: Every day Linux is growing in popularity, and in some cases becoming mandatory (there are growing numbers of companies that require Linux support in their RFQ's). As a result, every day there is a slow but steady pressure on hardware vendors to provide Linux support. Since binary drivers are "frowned upon" in Linux (i.e: "write a binary driver for us and we'll make your maintenance a living hell"), the chance of getting OpenSource drivers is growing steadily. I guess it's obvious where I stand here :-) Just a note: I'm sure you still remember the days Adaptec drivers for Linux were written by reverese engineering... Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron But it does move! -- Galileo Galilei -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] My Modem, the Kernel and Me
On Sun, Feb 23, 2003 at 12:50:59AM +0200, guy keren wrote: > > On Wed, 19 Feb 2003, Muli Ben-Yehuda wrote: > > > On Wed, Feb 19, 2003 at 11:58:16AM +0200, Eli Billauer wrote: > > > > > original configuration, and noone was really sure. I don't think that > > > there is someone here who can tell me exactly what files are tampered > > > with during all the makes (could syscalltrack be handy here? ;). All > > > this makes kernel compilation a mysterious adventure, with no promised > > > way back home. If there was as little as a list of directories to back > > > up before starting, it would all look different. > > > > Eli, > > > > It's not voodoo. It's not a mystery. It's code, plain and simple, > > there for the reading. Please read the Makefile and write a > > comprehensive list of files which are changed. I'm sure > > kernelnewbies.org will be happy to put it on line. > > actually, there's a contradiction there. if it was that simple, there > would be no need to write a doc for it and place on kernelnewbies. I didn't say it's "simple", I said it's "code, plain and simple". as in "you have the documentation, it's the code". > Makefiles are usually hard-code to read, and writing Makefiles which are > easy to maintain as well as easy to read, is a difficult task. > specifically, the Makefiles of the linux kernel are not easy to figure. > the fact that you deal with them for quite some time now, and you read > them rather easily, is not an evidence to how easy it is to read them for > the first time. this is especially tru when you have a specific goal in > mind (such as - how do i get this module to work). I agree here. > > > Don't take me wrong: I think that the possibility to compile the kernel > > > is one of the beauties of Linux, and writing in kernel space is > > > something I know I'll do sooner or later. The problem is that it's such > > > an unfriendly field, and for no real reason. > > > > Did you read the books? did you read the source? where else did you > > expect the knowledge to come from? > > from good documentation, ofcourse. the linux kernel comes with lots of > documentation, but without something large to show the architecture of the > beast, and how it all fits together. specifically, i'm not aware of good > documents that deal with the Makefiles - is there? for the kernel itself > there is 'the linux kernel' in the Linux Documentation Project - thoughts > its not deep enough for my taste. Linux Device Drivers, 2nd Edition (available online). Understanding the Linux Kernel, 2nd Edition (highly recommended). The linux-kernel mailing list archives. The lwn.net kernel summaries (very highly recommended), and kernel traffic. http://www.kerneltrap.com, http://www.kernelnewbies.org. As for the Makefiles specifically, in 2.5, 'make help' should be a pleasant surprise, the Makefile begins with a documentation section and there is Documentation/kbuild/*. 2.4 is not quite as well endowed, but neither is it completely lacking. > > > >c. Run 'make oldconfig; make dep'. This step prepares the intermediary > > > >kernel configuration and build files that are needed for the build > > > >process. Amongst other things, it handles module version. > > > > > > Thanks. "make oldconfig" was the secret. And a secret it is. Just for > > > the fun of it, does anyone know exactly what it does? What "old > > > configuration" are we talking about? And "make dep" afterward fixed > > > it all. > > > > It takes .config, all of the configuration symbols in this kernel, and > > only asks you about new or changed configuration options. It's used > > when you already built a kernel, and then a new version is > > released. You copy the same .config over and run 'make oldconfig', and > > instead of dealing with hundreds of configuration options, you only > > deal with the delta. > > > > As a side effect, it also creates some files that tell the build > > system that it has been configured, and (I think) creates the > > include/asm-$(ARCH) -> include/asm symlink. > > just as a note - i have been compiling linux kernels for several years, > before i heard about 'make oldconfig' for the first time - and i did read > some of the documentation that comes with the kernel during that time. in > fact, i got so used to reconfiguring it manually, that i keep forgetting > about 'make oldconfig', and thus configuring a new kernel keeps taking me > 30-60 minutes every time ;) You should start doing it 15 or 20 times at a stretch, that will cure your memory in a hurry ;-) Here's my currently running kernel: [EMAIL PROTECTED]:~$ uname -a Linux tea 2.5.62-mx #34 SMP Sat Feb 22 09:28:42 IST 2003 i686 unknown the #34 there means that it's the 34th compilation of this kernel tree... > > > >Start with the top level > > > >Makefile and Rules.make, and follow what happens when you run 'make > > > >oldconfig; make dep'. > > > > > > > Yeah, right. I wanted to install a linmodem driver,
Re: [Haifux] My Modem, the Kernel and Me
On Wed, 19 Feb 2003, Muli Ben-Yehuda wrote: > On Wed, Feb 19, 2003 at 11:58:16AM +0200, Eli Billauer wrote: > > > original configuration, and noone was really sure. I don't think that > > there is someone here who can tell me exactly what files are tampered > > with during all the makes (could syscalltrack be handy here? ;). All > > this makes kernel compilation a mysterious adventure, with no promised > > way back home. If there was as little as a list of directories to back > > up before starting, it would all look different. > > Eli, > > It's not voodoo. It's not a mystery. It's code, plain and simple, > there for the reading. Please read the Makefile and write a > comprehensive list of files which are changed. I'm sure > kernelnewbies.org will be happy to put it on line. actually, there's a contradiction there. if it was that simple, there would be no need to write a doc for it and place on kernelnewbies. Makefiles are usually hard-code to read, and writing Makefiles which are easy to maintain as well as easy to read, is a difficult task. specifically, the Makefiles of the linux kernel are not easy to figure. the fact that you deal with them for quite some time now, and you read them rather easily, is not an evidence to how easy it is to read them for the first time. this is especially tru when you have a specific goal in mind (such as - how do i get this module to work). > > Don't take me wrong: I think that the possibility to compile the kernel > > is one of the beauties of Linux, and writing in kernel space is > > something I know I'll do sooner or later. The problem is that it's such > > an unfriendly field, and for no real reason. > > Did you read the books? did you read the source? where else did you > expect the knowledge to come from? from good documentation, ofcourse. the linux kernel comes with lots of documentation, but without something large to show the architecture of the beast, and how it all fits together. specifically, i'm not aware of good documents that deal with the Makefiles - is there? for the kernel itself there is 'the linux kernel' in the Linux Documentation Project - thoughts its not deep enough for my taste. > > >c. Run 'make oldconfig; make dep'. This step prepares the intermediary > > >kernel configuration and build files that are needed for the build > > >process. Amongst other things, it handles module version. > > > > Thanks. "make oldconfig" was the secret. And a secret it is. Just for > > the fun of it, does anyone know exactly what it does? What "old > > configuration" are we talking about? And "make dep" afterward fixed > > it all. > > It takes .config, all of the configuration symbols in this kernel, and > only asks you about new or changed configuration options. It's used > when you already built a kernel, and then a new version is > released. You copy the same .config over and run 'make oldconfig', and > instead of dealing with hundreds of configuration options, you only > deal with the delta. > > As a side effect, it also creates some files that tell the build > system that it has been configured, and (I think) creates the > include/asm-$(ARCH) -> include/asm symlink. just as a note - i have been compiling linux kernels for several years, before i heard about 'make oldconfig' for the first time - and i did read some of the documentation that comes with the kernel during that time. in fact, i got so used to reconfiguring it manually, that i keep forgetting about 'make oldconfig', and thus configuring a new kernel keeps taking me 30-60 minutes every time ;) > > >Start with the top level > > >Makefile and Rules.make, and follow what happens when you run 'make > > >oldconfig; make dep'. > > > > > Yeah, right. I wanted to install a linmodem driver, not explore the > > mysteries of makefile, sed and bash, and virtually every possible system > > file. > > You want knowledge. I told you where it is found. sometimes, this is like sending people to look for a needle in a haystack (thanks for 'man strstr' for showing me the proper spelling). what you say is 'installing a linmodem driver requires good understanding of the kernel build system'. as a comparison, apache has 'extension modules', which can be compared to device driver modules. the apache team made osme work to make it easier to compile such modules - and wrote documentation specifying how to get this done. nobody did that for the kernel, so far. > > I have only one explanation for all this: Kernel hackers enjoy the > > exclusiveness of their status. It's Open Source, but closed society. You > > want to join it, fine, but you'll have to go through some acceptance > > tests before you can do anything. > > No. You'll have to invest effort and show that you know what you are > doing. Otherwise, just pay someone to do it for you. muli, i think you're confusing the developers and the users. for a developer, it is ok to expect them to learn how the thin
Re: [Haifux] My Modem, the Kernel and Me
On Wed, Feb 19, 2003 at 01:57:39PM +0200, Eli Billauer wrote: > So it actually *is* simple, only somehow this is never mentioned. Kernel > hackers probably want us to suffer before we can get a working > configuration, rather than slightly modifying and already working > setup. :-( Actually, the problem of compiling modules "out of tree" is an acute problem, and it's usually broken in one or another way. Kernel hackers prefer for kernel source to be shipped with the kernel (or as a patch to the kernel source), and every module which doesn't is automatically a step child. -- Muli Ben-Yehuda http://www.mulix.org http://syscalltrack.sf.net -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] My Modem, the Kernel and Me
On Wed, Feb 19, 2003 at 01:47:41PM +0200, Tzafrir Cohen wrote: > In the worst case it is the full kernel comiplation tree . But are all of > those files really necessary? No. You need a .config, 'make oldconfig' and 'make dep' (in 2.4, it's obsolete in 2.5). That's it. -- Muli Ben-Yehuda http://www.mulix.org http://syscalltrack.sf.net -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] My Modem, the Kernel and Me
On Wed, Feb 19, 2003 at 11:58:16AM +0200, Eli Billauer wrote: > original configuration, and noone was really sure. I don't think that > there is someone here who can tell me exactly what files are tampered > with during all the makes (could syscalltrack be handy here? ;). All > this makes kernel compilation a mysterious adventure, with no promised > way back home. If there was as little as a list of directories to back > up before starting, it would all look different. Eli, It's not voodoo. It's not a mystery. It's code, plain and simple, there for the reading. Please read the Makefile and write a comprehensive list of files which are changed. I'm sure kernelnewbies.org will be happy to put it on line. > Don't take me wrong: I think that the possibility to compile the kernel > is one of the beauties of Linux, and writing in kernel space is > something I know I'll do sooner or later. The problem is that it's such > an unfriendly field, and for no real reason. Did you read the books? did you read the source? where else did you expect the knowledge to come from? > >c. Run 'make oldconfig; make dep'. This step prepares the intermediary > >kernel configuration and build files that are needed for the build > >process. Amongst other things, it handles module version. > > Thanks. "make oldconfig" was the secret. And a secret it is. Just for > the fun of it, does anyone know exactly what it does? What "old > configuration" are we talking about? And "make dep" afterward fixed > it all. It takes .config, all of the configuration symbols in this kernel, and only asks you about new or changed configuration options. It's used when you already built a kernel, and then a new version is released. You copy the same .config over and run 'make oldconfig', and instead of dealing with hundreds of configuration options, you only deal with the delta. As a side effect, it also creates some files that tell the build system that it has been configured, and (I think) creates the include/asm-$(ARCH) -> include/asm symlink. > And you were right about the /boot directory. There are config-files for > each binary to boot, so it seems like the way to just recompile a > certain prebuilt binary is to copy one of these into > /usr/src/linux-x.x.xx/.config . This might be the answer to my original > question: How do I turn things back to where they were? But I haven't > really tried this, though. I might soon. You save your .config and run 'make mrproper', which is like 'make distclean' in user space. NOTE that 'make mrproper' WILL remove all files which match the pattern "*config*" or a variation on it. That's why you save your .config before beginning. > BTW, I didn't compile the kernel in the end. There was no reason to. Sounds to me like you should do it for the same reason people jump out of airplanes - to see that you can. > >Start with the top level > >Makefile and Rules.make, and follow what happens when you run 'make > >oldconfig; make dep'. > > > Yeah, right. I wanted to install a linmodem driver, not explore the > mysteries of makefile, sed and bash, and virtually every possible system > file. You want knowledge. I told you where it is found. > I have only one explanation for all this: Kernel hackers enjoy the > exclusiveness of their status. It's Open Source, but closed society. You > want to join it, fine, but you'll have to go through some acceptance > tests before you can do anything. No. You'll have to invest effort and show that you know what you are doing. Otherwise, just pay someone to do it for you. -- Muli Ben-Yehuda http://www.mulix.org http://syscalltrack.sf.net -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] My Modem, the Kernel and Me
Why isn't there any package "kernel-devel" that would include all the required files necessary to compile files based on a certain binary kernel from my distro? Actually, that's exactly /usr/src/linux-xx.xx.xx . And what I seem to have (re)discovered, the config files reside in the /boot directory. So it actually *is* simple, only somehow this is never mentioned. Kernel hackers probably want us to suffer before we can get a working configuration, rather than slightly modifying and already working setup. :-( In the worst case it is the full kernel comiplation tree . But are all of those files really necessary? Who cares? As long as I don't have to understand each and every one. The problem is that some people send us all to read them all... Eli
Re: [Haifux] My Modem, the Kernel and Me
Elaboration on the previous post On Wed, 19 Feb 2003, Tzafrir Cohen wrote: > On Wed, 19 Feb 2003, Eli Billauer wrote: > > > I clearly remember asking during a Haifux lecture, how I get back to the > > original configuration, and noone was really sure. I don't think that > > there is someone here who can tell me exactly what files are tampered > > with during all the makes (could syscalltrack be handy here? ;). > > Installation currently requires kernel recompilation ;-) Sorry: I meant: a compiled kernel tree. Basically the same requirements as for the modem module. > > > Don't take me wrong: I think that the possibility to compile the kernel > > is one of the beauties of Linux, and writing in kernel space is > > something I know I'll do sooner or later. The problem is that it's such > > an unfriendly field, and for no real reason. > > > > Fully agree Why isn't there any package "kernel-devel" that would include all the required files necessary to compile files based on a certain binary kernel from my distro? All those files have been created when the kernel image packae was created. It is basically amatter of shoosing what should go in there and what not. In the worst case it is the full kernel comiplation tree . But are all of those files really necessary? -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] My Modem, the Kernel and Me
On Wed, 19 Feb 2003, Eli Billauer wrote: > I clearly remember asking during a Haifux lecture, how I get back to the > original configuration, and noone was really sure. I don't think that > there is someone here who can tell me exactly what files are tampered > with during all the makes (could syscalltrack be handy here? ;). Installation currently requires kernel recompilation ;-) > Don't take me wrong: I think that the possibility to compile the kernel > is one of the beauties of Linux, and writing in kernel space is > something I know I'll do sooner or later. The problem is that it's such > an unfriendly field, and for no real reason. > Fully agree -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] My Modem, the Kernel and Me
Hello Muli and all, 1. What have I done to deserve this? Tried to solve the problem with one hand tied behind your back? (the "no recompiling the kernel" rule). My problem was not being able to compile a small directory with drivers, and my case only proves that only playing with the kernel configuration toys can get you into a mess. I clearly remember asking during a Haifux lecture, how I get back to the original configuration, and noone was really sure. I don't think that there is someone here who can tell me exactly what files are tampered with during all the makes (could syscalltrack be handy here? ;). All this makes kernel compilation a mysterious adventure, with no promised way back home. If there was as little as a list of directories to back up before starting, it would all look different. Don't take me wrong: I think that the possibility to compile the kernel is one of the beauties of Linux, and writing in kernel space is something I know I'll do sooner or later. The problem is that it's such an unfriendly field, and for no real reason. c. Run 'make oldconfig; make dep'. This step prepares the intermediary kernel configuration and build files that are needed for the build process. Amongst other things, it handles module version. Thanks. "make oldconfig" was the secret. And a secret it is. Just for the fun of it, does anyone know exactly what it does? What "old configuration" are we talking about? And "make dep" afterward fixed it all. And you were right about the /boot directory. There are config-files for each binary to boot, so it seems like the way to just recompile a certain prebuilt binary is to copy one of these into /usr/src/linux-x.x.xx/.config . This might be the answer to my original question: How do I turn things back to where they were? But I haven't really tried this, though. I might soon. BTW, I didn't compile the kernel in the end. There was no reason to. d. Pray. "O Almighty Makefile, whose ways are unknown to man, have mercy upon me and give my computer peace, prosperity and harmony. And bootability" Start with the top level Makefile and Rules.make, and follow what happens when you run 'make oldconfig; make dep'. Yeah, right. I wanted to install a linmodem driver, not explore the mysteries of makefile, sed and bash, and virtually every possible system file. I have only one explanation for all this: Kernel hackers enjoy the exclusiveness of their status. It's Open Source, but closed society. You want to join it, fine, but you'll have to go through some acceptance tests before you can do anything. Regards, Eli
Re: [Haifux] My Modem, the Kernel and Me
On Tue, Feb 18, 2003 at 04:37:29PM +0200, Eli Billauer wrote: > 1. What have I done to deserve this? Tried to solve the problem with one hand tied behind your back? (the "no recompiling the kernel" rule). > 2. How can I synchronize between the symbols that I have in > usr/src/linux/include/linux/module/ and those that are actually loaded > into the kernel? I don't want to recompile the kernel. a. Get the *exact* redhat kernel source rpm for the kernel you are running. b. Copy into the source directory the .config that was used to build that kernel. I think redhat puts the configs under linux/configs/, or they might be under /boot somewhere. c. Run 'make oldconfig; make dep'. This step prepares the intermediary kernel configuration and build files that are needed for the build process. Amongst other things, it handles module version. d. Pray. > 3. Most important: Is there any guide around, for free or for $$$, that > spares the endless search on the web for solutions? There are plently of > one-pagers who tell me to do a lot of make-make-make, but I still > haven't found a single guide that tells me, at least, what files are > involved. And to what extent every step I take screws the system up. Linux Device Drivers talks about this, but not in sufficient details. You can scourge the linux-kernel mailing list archives, where this subject was discussed repeatedly. You can read the source, where ultimately all questions are answered. Start with the top level Makefile and Rules.make, and follow what happens when you run 'make oldconfig; make dep'. -- Muli Ben-Yehuda http://www.mulix.org http://syscalltrack.sf.net -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] My Modem, the Kernel and Me
Hello all, I'm doing my best to install the drivers for the 536ep modem on my RH 7.3. Which drives me nuts. I'm talking about unresolved symbols with depmod. The thing is, that my kernel has module versions, which is a nice thing in itself, but... I'll spare you the via dolorosa until I figured out, that I'll need to add the -DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h compile options when I compile the modules. Then I did get some version tags on the functions (in the newly compiled module files), but the tags were unmatching those of the system, so the symbols remained unresolved. Reason: The symbols of the module files were all smp-tagged. Uhh. A few blown grey cells later, it occured to me, that the reason was that I messed with the kernel configuration a few months ago. So I set up the kernel configuration back to non-smp (and no, I didn't compile the kernel), as if I was about to compile it for non-SMP, and voila, the version tags matched much better. "Much better" means all but a few. The session at the end of this posting explains it all. And no, I didn't actually compile the kernel. I'm faithful to RH7.3's binary. Enough trouble as is. For example, in /usr/src/linux/include/linux/module/ksyms.ver we have #define __ver_tty_register_driverea3edd78 but in /proc/ksyms it appears as tty_register_driver_Ra1c6c9cb (see below). So this leaves me with three questions: 1. What have I done to deserve this? 2. How can I synchronize between the symbols that I have in usr/src/linux/include/linux/module/ and those that are actually loaded into the kernel? I don't want to recompile the kernel. 3. Most important: Is there any guide around, for free or for $$$, that spares the endless search on the web for solutions? There are plently of one-pagers who tell me to do a lot of make-make-make, but I still haven't found a single guide that tells me, at least, what files are involved. And to what extent every step I take screws the system up. Thanks in advance, Eli -- And here's the session: [root@localhost Intel-536ep-451-R73]# depmod -e depmod: *** Unresolved symbols in /lib/modules/2.4.18-3/kernel/drivers/char/536ep.o depmod: tty_register_driver_Rea3edd78 depmod: tty_flip_buffer_push_Rfc595416 depmod: tty_unregister_driver_R86cec9d5 depmod: *** Unresolved symbols in /lib/modules/2.4.18-3/kernel/drivers/char/536epcore.o depmod: create_proc_entry_R1231106e depmod: remove_proc_entry_R391b3f4c depmod: proc_root_R2c857f25 [root@localhost Intel-536ep-451-R73]# grep tty_register_driver /proc/ksyms c016e230 tty_register_driver_Ra1c6c9cb [root@localhost Intel-536ep-451-R73]# grep create_proc_entry /proc/ksyms c0157cc0 create_proc_entry_Ra60a30fa -- Haifa Linux Club Mailing List (http://www.haifux.org) To unsub send an empty message to [EMAIL PROTECTED]
