From: Norbert P. <pre...@lo...> - 2003-05-11 16:12:21
|
Hi! I have just build the smartmontools for our debian woody server from the sid sources, and wanted to run it to monitor our disks, but found: gamma:~# smartctl -a /dev/hda smartctl version 5.1-11 Copyright (C) 2002-3 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: IC35L060AVV207-0 Serial Number: VNVB07G2RHU48L Firmware Version: V22OA63A Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 6 ATA Standard is: ATA/ATAPI-6 T13 1410D revision 3a Local Time is: Sun May 11 18:03:48 2003 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled Error SMART Status command via HDIO_DRIVE_TASK failed: Input/output error Rebuild older linux 2.2 kernels with HDIO_DRIVE_TASK support enabled A mandatory SMART command has failed: exiting. To continue, use the -T option to set the tolerance level to 'permissive' =========================0 We have kernel 2.2.25 running here, nothing patched in. I thought that later (2.2.25 is latest) kernels provide HDIO_DRIVE_TASK. But, alas, it looks like it doesn't. And searching google for smartmontools HDIO_DRIVE_TASK kernel 2.2 didn't show up anything, searching in the mailing list for 2.2 patch also nothing. Can you provide me with a pointer to a kernel patch allowing the usage of smartmontools. Preferably a not extremely intrusive one producing any instability ;-) Thanks a lot for any help, please Cc me any answers since I am not subscribed to the mailing list. Best wishes Norbert ------------------------------------------------------------------------------- Norbert Preining <preining AT logic DOT at> Technische Universität Wien gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- QUERRIN (n.) A person that no one has ever heard of who unaccountably manages to make a living writing prefaces. --- Douglas Adams, The Meaning of Liff |
From: <sou...@tv...> - 2003-05-11 21:28:12
|
On Sun, 11 May 2003, Norbert Preining wrote: >Can you provide me with a pointer to a kernel patch allowing the usage >of smartmontools. Preferably a not extremely intrusive one producing any >instability ;-) Well. Found one, but it _is_ quite intrusive and intended for 2.2.20. ftp://ftp.funet.fi/pub/linux/kernel/people/hedrick/ide-2.2.20/ This: http://user.it.uu.se/~mikpe/linux/patches/2.2/ide.2.2.25.05042001.patch.bz2 seems to be an unofficial 2.2.25 port of an earlier version of it, and obviously I can't vouch for its workings and usefulness at all. Do test them, if you feel lucky and have recent backups. But I have a hunch that upgrading to a 2.4.x kernel would be more advisable. -- Erik I. Bolsø | email: <knan at mo.himolde.no> The UNIX philosophy basically involves giving you enough rope to hang yourself. And then a couple of feet more, just to be sure. |
From: Bruce A. <ba...@gr...> - 2003-05-12 14:48:44
|
Erik, Thanks very much for looking into this. If you could add these pointers/info to the FAQ section of the smartmontools web page, I'd be grateful. Likewise, if you could add the addresses to the smartmontools error message in atacmds.c, that would be nice. Note that there are two error messages -- one if HDIO_DRIVE_TASK is missing from the header files, and one if the ioctl() simply fails. Norbert, I'd be grateful to know if/how you are able to fix this. The strange thing is that the header files you are using DO define HDIO_DRIVE_TASK, but the kernel doesn't appear to implement it. Cheers, =09Bruce On Sun, 11 May 2003, Erik Inge Bols=F8 wrote: > On Sun, 11 May 2003, Norbert Preining wrote: > >Can you provide me with a pointer to a kernel patch allowing the usage > >of smartmontools. Preferably a not extremely intrusive one producing any > >instability ;-) >=20 > Well. Found one, but it _is_ quite intrusive and intended for 2.2.20. >=20 > ftp://ftp.funet.fi/pub/linux/kernel/people/hedrick/ide-2.2.20/ >=20 > This: > http://user.it.uu.se/~mikpe/linux/patches/2.2/ide.2.2.25.05042001.patch.b= z2 > seems to be an unofficial 2.2.25 port of an earlier version of it, and > obviously I can't vouch for its workings and usefulness at all. >=20 > Do test them, if you feel lucky and have recent backups. But I have a > hunch that upgrading to a 2.4.x kernel would be more advisable. >=20 > -- > Erik I. Bols=F8 | email: <knan at mo.himolde.no> > The UNIX philosophy basically involves giving you enough rope to > hang yourself. And then a couple of feet more, just to be sure. >=20 >=20 > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com >=20 > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support >=20 |
From: Norbert P. <pre...@lo...> - 2003-05-12 16:05:20
|
Hi Bruce, Erik, list! On Mon, 12 Mai 2003, Bruce Allen wrote: > Norbert, I'd be grateful to know if/how you are able to fix this. The > strange thing is that the header files you are using DO define > HDIO_DRIVE_TASK, but the kernel doesn't appear to implement it. I don't think so. A grep over all .c and .h files in my linux-2.2.25 didn't find anything: $ find . -name \*.c -or -name \*.h | xargs grep HDIO_DRIVE_TASK $ So it seems that this is neither in the kernel nor in the header files. And, I will NOT use the 2.4-ide backport, since I am not sure how well it works and who safe my data are. This is a server for a whole institute I cannot gamble around ;-) I think I will switch to 2.4.21+ext3 as soon as it is out and see if I get everything working. I do NOT think that it is a good idea to advise people to use a backport of 2.4-ide which is not maintained and not patched for tasks like this. Best wishes Norbert ------------------------------------------------------------------------------- Norbert Preining <preining AT logic DOT at> Technische Universität Wien gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- SWANIBOST (adj.) Complete shagged out after a hard day having income tax explained to you. --- Douglas Adams, The Meaning of Liff |
From: Bruce A. <ba...@gr...> - 2003-05-12 17:09:33
|
Norbert, > On Mon, 12 Mai 2003, Bruce Allen wrote: > > Norbert, I'd be grateful to know if/how you are able to fix this. The > > strange thing is that the header files you are using DO define > > HDIO_DRIVE_TASK, but the kernel doesn't appear to implement it. > > I don't think so. A grep over all .c and .h files in my linux-2.2.25 > didn't find anything: > $ find . -name \*.c -or -name \*.h | xargs grep HDIO_DRIVE_TASK > $ > So it seems that this is neither in the kernel nor in the header files. Ah, OK, I understand. You are using a pre-compiled binary that was built on a machine that DID have HDIO_DRIVE_TASK defined, but your machine doesn't. OK. I apologize -- what I said was wrong. > And, I will NOT use the 2.4-ide backport, since I am not sure how well > it works and who safe my data are. This is a server for a whole > institute I cannot gamble around ;-) > > I think I will switch to 2.4.21+ext3 as soon as it is out and see if I > get everything working. > > I do NOT think that it is a good idea to advise people to use a backport > of 2.4-ide which is not maintained and not patched for tasks like this. Noted. Cheers, Bruce |
From: Guido G. <ag...@si...> - 2003-05-12 18:35:53
|
Hi Bruce, On Mon, May 12, 2003 at 12:09:08PM -0500, Bruce Allen wrote: > > I don't think so. A grep over all .c and .h files in my linux-2.2.25 > > didn't find anything: > > $ find . -name \*.c -or -name \*.h | xargs grep HDIO_DRIVE_TASK > > $ > > So it seems that this is neither in the kernel nor in the header files. > > Ah, OK, I understand. You are using a pre-compiled binary that was built > on a machine that DID have HDIO_DRIVE_TASK defined, but your machine > doesn't. > > OK. I apologize -- what I said was wrong. Just to get this straight. smartmontools doesn't (and will never) work on a vanilla 2.2.X kernel, correct? If so, I'd like to add a note to README.Debian. Regards, -- Guido |
From: Bruce A. <ba...@gr...> - 2003-05-12 19:18:54
|
Hi Guido, On Mon, 12 May 2003, Guido Guenther wrote: > Hi Bruce, > On Mon, May 12, 2003 at 12:09:08PM -0500, Bruce Allen wrote: > > > I don't think so. A grep over all .c and .h files in my linux-2.2.25 > > > didn't find anything: > > > $ find . -name \*.c -or -name \*.h | xargs grep HDIO_DRIVE_TASK > > > $ > > > So it seems that this is neither in the kernel nor in the header files. > > > > Ah, OK, I understand. You are using a pre-compiled binary that was built > > on a machine that DID have HDIO_DRIVE_TASK defined, but your machine > > doesn't. > > > > OK. I apologize -- what I said was wrong. > Just to get this straight. smartmontools doesn't (and will never) work > on a vanilla 2.2.X kernel, correct? If so, I'd like to add a note to > README.Debian. I'd tell you, but I am genuinely not sure. It does need HDIO_DRIVE_TASK available in order to get the SMART status from the disk, so if vanilla 2.2.X does not have this, then it won't work. But I was under the impression that at least some 2.2.X kernels do have this support. Cheers, Bruce |
From: <sou...@tv...> - 2003-05-12 22:18:46
|
On Mon, 12 May 2003, Bruce Allen wrote: >On Mon, 12 May 2003, Guido Guenther wrote: >> Just to get this straight. smartmontools doesn't (and will never) work >> on a vanilla 2.2.X kernel, correct? If so, I'd like to add a note to >> README.Debian. > >I'd tell you, but I am genuinely not sure. It does need HDIO_DRIVE_TASK >available in order to get the SMART status from the disk, so if vanilla >2.2.X does not have this, then it won't work. But I was under the >impression that at least some 2.2.X kernels do have this support. As far as I can tell, for the 2.2.X series, only the Andre Hedrick patches have this. They have not been officially updated for 2.2.21 or later kernels, and probably have bugs in them still. The reason for the confusion is probably this: At one time (uhm, make that several times), Andre's patches was pretty much the only way to get newer chipsets working - like the Highpoint ATA/66 controllers, various Promise controllers, etc. This persisted for several months, during which time those patches became quite common. And so Mandrake, and quite possibly other vendors, included the patches into their vendor kernels, in order to address customers asking about support for these fine new chipsets. (kernel22-source-2.2.20-9mdk has ide-taskfile.c, which is a telltale sign of a Andre-patched IDE subsystem. It's not included in vanilla 2.2.X kernels.) So as for your question: no, it won't work on any vanilla kernel.org 2.2.X kernel. Vendor kernels are another matter, which I know little about. Just a bit of remembered cursing and a bit of research. -- Erik I. Bolsø | email: <knan at mo.himolde.no> The UNIX philosophy basically involves giving you enough rope to hang yourself. And then a couple of feet more, just to be sure. |
From: Bruce A. <ba...@gr...> - 2003-05-13 14:19:56
|
Erik, Thank you very much for the detailed explanation. Could you please add a few sentences to the smartmontools web page FAQ section about this? Just search for the word "kernel" to find the relevant section(s). Cheers, =09Bruce On Tue, 13 May 2003, Erik Inge Bols=F8 wrote: > On Mon, 12 May 2003, Bruce Allen wrote: > >On Mon, 12 May 2003, Guido Guenther wrote: > >> Just to get this straight. smartmontools doesn't (and will never) work > >> on a vanilla 2.2.X kernel, correct? If so, I'd like to add a note to > >> README.Debian. > > > >I'd tell you, but I am genuinely not sure. It does need HDIO_DRIVE_TASK > >available in order to get the SMART status from the disk, so if vanilla > >2.2.X does not have this, then it won't work. But I was under the > >impression that at least some 2.2.X kernels do have this support. >=20 > As far as I can tell, for the 2.2.X series, only the Andre Hedrick patche= s > have this. They have not been officially updated for 2.2.21 or later > kernels, and probably have bugs in them still. >=20 > The reason for the confusion is probably this: At one time (uhm, > make that several times), Andre's patches was pretty much the only way to > get newer chipsets working - like the Highpoint ATA/66 controllers, > various Promise controllers, etc. This persisted for several months, > during which time those patches became quite common. >=20 > And so Mandrake, and quite possibly other vendors, included the patches > into their vendor kernels, in order to address customers asking about > support for these fine new chipsets. >=20 > (kernel22-source-2.2.20-9mdk has ide-taskfile.c, which is a telltale sign > of a Andre-patched IDE subsystem. It's not included in vanilla 2.2.X > kernels.) >=20 > So as for your question: no, it won't work on any vanilla kernel.org 2.2.= X > kernel. Vendor kernels are another matter, which I know little about. Jus= t > a bit of remembered cursing and a bit of research. >=20 > -- > Erik I. Bols=F8 | email: <knan at mo.himolde.no> > The UNIX philosophy basically involves giving you enough rope to > hang yourself. And then a couple of feet more, just to be sure. >=20 >=20 > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com >=20 > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support >=20 |
From: <sou...@tv...> - 2003-05-14 19:32:42
|
On Tue, 13 May 2003, Bruce Allen wrote: >Thank you very much for the detailed explanation. Could you please add a >few sentences to the smartmontools web page FAQ section about this? Just >search for the word "kernel" to find the relevant section(s). Done. Tell me if it's still unclear in the FAQ, my english get convoluted at times :) -- Erik I. Bolsø | email: <knan at mo.himolde.no> The UNIX philosophy basically involves giving you enough rope to hang yourself. And then a couple of feet more, just to be sure. |
From: Bruce A. <ba...@gr...> - 2003-05-14 19:37:24
|
Erik, It looks good -- thank you -- English is fine -- I have uploaded it to sourceforge. But how about adding the URLs for Hedrick's 2.2 kernel patches? Cheers, =09Bruce On Wed, 14 May 2003, Erik Inge Bols=F8 wrote: > On Tue, 13 May 2003, Bruce Allen wrote: > >Thank you very much for the detailed explanation. Could you please add a > >few sentences to the smartmontools web page FAQ section about this? Jus= t > >search for the word "kernel" to find the relevant section(s). >=20 > Done. Tell me if it's still unclear in the FAQ, my english get convoluted > at times :) >=20 > -- > Erik I. Bols=F8 | email: <knan at mo.himolde.no> > The UNIX philosophy basically involves giving you enough rope to > hang yourself. And then a couple of feet more, just to be sure. >=20 |
From: Bruce A. <ba...@gr...> - 2003-07-25 06:41:07
|
Hi Erik, On Wed, 14 May 2003, Erik Inge Bols=F8 wrote: > On Tue, 13 May 2003, Bruce Allen wrote: > >Thank you very much for the detailed explanation. Could you please add a > >few sentences to the smartmontools web page FAQ section about this? Jus= t > >search for the word "kernel" to find the relevant section(s). >=20 > Done. Tell me if it's still unclear in the FAQ, my english get convoluted > at times :) An email just came to the support list, about a user (Robert Peter) who said that=20 "Hello group! For what option of smartmontools do I really need the CONFIG_IDE_TASK_IOCTL option in the kernel? I have my kernel built without it and see no errors while executing tests and so." In the FAQ on the home page you'd written: "Any 2.4.X series kernel should work in principle, if it has been compiled with the right config options (see below) - both vanilla and vendor-supplied. For the 2.2.X series, life is more interesting. 2.0.X and earlier is right out. Vanilla kernel.org 2.2.X kernels do not support the needed HDIO_DRIVE_TASK ioctl(). This is needed for the ATA drive to execute the ATA SMART RETURN STATUS command. Vendor-supplied kernels, and vanilla kernels patched with Andre Hedrick's IDE patches (available from your local kernel.org mirror, not updated for 2.2.21 or later, and probably still have a few bugs), may support the needed ioctl(). For both 2.2 and 2.4: The kernel must have been compiled with CONFIG_IDE_TASK_IOCTL=3Dy, if that config option exists in the kernel version in question." I'm not sure if the connection between HDIO_DRIVE_TASK and CONFIG_IDE_TASK_IOCTL is correct. In the kernel (current 2.4.20, drivers/ide/ide.c is the only reference to CONFIG_IDE_TASK_IOCTL, where it says: #ifdef CONFIG_IDE_TASK_IOCTL <snip stuff unrelated to HDIO_DRIVE_TASK> } #endif /* CONFIG_IDE_TASK_IOCTL */ <snip stuff unrelated to HDIO_DRIVE_TASK> case HDIO_DRIVE_TASK: Note the last line: case HDIO_DRIVE_TASK lies *outside* the CONFIG_IDE_TASK_IOCTL block! In addition, I am using a stock redhat 7.3 kernel on my laptop: Linux lap 2.4.20-19.7 #1 Tue Jul 15 13:44:14 EDT 2003 i686 unknown and according to the config file, CONFIG_IDE_TASK_IOCTL is not defined! And all the smartmontools ATA functionality is just fine. So I think something is wrong with the FAQ documentation, but am not sure how to fix it. Perhaps for some previous kernels, CONFIG_IDE_TASK_IOCTL *was* needed for getting HDIO_DRIVE_TASK support. Can you shed any light on this?? I am confused -- I wish there was a CVS archive for the linux kernel. It would make this kind of detective work a bit simpler. Cheers, =09Bruce |
From: <kn...@mo...> - 2003-07-31 12:41:27
|
On Fri, 25 Jul 2003, Bruce Allen wrote: >So I think something is wrong with the FAQ documentation, but am not sure >how to fix it. Perhaps for some previous kernels, CONFIG_IDE_TASK_IOCTL >*was* needed for getting HDIO_DRIVE_TASK support. > >Can you shed any light on this?? I am confused -- I wish there was a CVS >archive for the linux kernel. It would make this kind of detective work a >bit simpler. Hmm. I've checked now, with 2.4.19 and a patched 2.2.25 I'm building for a monitoring server, and it seems you're right. CONFIG_IDE_TASK_IOCTL has probably never been needed. I've confused the ioctls HDIO_DRIVE_TASK and HDIO_DRIVE_TASKFILE when checking. Any 2.4 kernel is ok, it seems, without any special config options. Checked 2.4.0 and 2.4.19. For 2.2, the following holds: Unless your kernel has the _option_ CONFIG_IDE_TASK_IOCTL - which implies that it is patched with new-style ide and HDIO_DRIVE_TASK (and HDIO_DRIVE_TASKFILE) is in place - it won't support smartmontools. I'll update the FAQ this week, I hope. Another thing I just noted: http://www.cs.helsinki.fi/linux/linux-kernel/2003-19/0113.html Bartlomiej Zolnierkiewicz (2.6 ide maintainer) seems to want to obsolete HDIO_DRIVE_TASK during 2.6 and remove it in 2.7. It would perhaps be good to find out what the new way of doing things is? -- Erik I. Bolsø | email: <knan at mo.himolde.no> The UNIX philosophy basically involves giving you enough rope to hang yourself. And then a couple of feet more, just to be sure. |
From: Bruce A. <ba...@gr...> - 2003-07-31 12:52:15
|
Hi Erik, > On Fri, 25 Jul 2003, Bruce Allen wrote: > >So I think something is wrong with the FAQ documentation, but am not sure > >how to fix it. Perhaps for some previous kernels, CONFIG_IDE_TASK_IOCTL > >*was* needed for getting HDIO_DRIVE_TASK support. > > > >Can you shed any light on this?? I am confused -- I wish there was a CVS > >archive for the linux kernel. It would make this kind of detective work a > >bit simpler. > > Hmm. I've checked now, with 2.4.19 and a patched 2.2.25 I'm building for > a monitoring server, and it seems you're right. > > CONFIG_IDE_TASK_IOCTL has probably never been needed. I've confused > the ioctls HDIO_DRIVE_TASK and HDIO_DRIVE_TASKFILE when checking. > > Any 2.4 kernel is ok, it seems, without any special config options. > Checked 2.4.0 and 2.4.19. OK, clear enough. 2.4.X needs nothing special in its configuration. > For 2.2, the following holds: Unless your kernel has the _option_ > CONFIG_IDE_TASK_IOCTL - which implies that it is patched > with new-style ide and HDIO_DRIVE_TASK (and HDIO_DRIVE_TASKFILE) is in > place - it won't support smartmontools. OK. Just to reiterate - a stock 2.2.X kernel won't work. One needs a 2.2.X kernel that is patched. And if it is patched, then it will have the CONFIG_IDE_TASK_IOCTL present. It doesn't matter whether this option is enabled or disabled. But if it's not there, then HDIO_DRIVE_TASK is missing and smartmontools isn't supported. > I'll update the FAQ this week, I hope. Thank you! I've been puzzled about this for a long time -- I appreciate your finally sorting it out for me. Please, when you update the FAQ in the home page, could you also please update the README file, which has similar statements? > Another thing I just noted: > > http://www.cs.helsinki.fi/linux/linux-kernel/2003-19/0113.html > > Bartlomiej Zolnierkiewicz (2.6 ide maintainer) seems to want to obsolete > HDIO_DRIVE_TASK during 2.6 and remove it in 2.7. It would perhaps be good > to find out what the new way of doing things is? Yes, thank you for calling this to my attention -- it's something I didn't realize or know. I'll follow through with this. Cheers, Bruce |
From: Norbert P. <pre...@lo...> - 2003-05-12 20:35:31
|
Hi Bruce! On Mon, 12 Mai 2003, Bruce Allen wrote: > Ah, OK, I understand. You are using a pre-compiled binary that was built > on a machine that DID have HDIO_DRIVE_TASK defined, but your machine > doesn't. No. I compiled the smartmontools myself, backported it to woody (well, just recompiled it for woody). The point is that the inlcude files in /usr/include/linux belong to the libc and always SHOULD be used from the installed libc, while in the kernel headers from /usr/src/linux-2.2.25/include the HDIO_DRIVE_TASK is not defined. Best wishes Norbert ------------------------------------------------------------------------------- Norbert Preining <preining AT logic DOT at> Technische Universität Wien gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- BURWASH The pleasurable cool sloosh of puddle water over the toes of your gumboots. --- Douglas Adams, The Meaning of Liff |
From: Bruce A. <ba...@gr...> - 2003-05-12 22:04:44
|
On Mon, 12 May 2003, Norbert Preining wrote: > On Mon, 12 Mai 2003, Bruce Allen wrote: > > Ah, OK, I understand. You are using a pre-compiled binary that was built > > on a machine that DID have HDIO_DRIVE_TASK defined, but your machine > > doesn't. > > No. I compiled the smartmontools myself, backported it to woody (well, > just recompiled it for woody). The point is that the inlcude files in > /usr/include/linux belong to the libc and always SHOULD be used from the > installed libc, while in the kernel headers from > /usr/src/linux-2.2.25/include the HDIO_DRIVE_TASK is not defined. Oh my. This really isn't "the way it should be". Since for the various hard disk ioctls() of course we want to use the headers/ioctls/data structures that the KERNEL was built with not the ones that GCC was built with. These headers can often be found (Redhat distributions, anyway) under /lib/modules/*/build. Is there any "standard location" for the actual runnnig kernel's header files? [The Makefile actually has the following commented out, that I was experimenting with: # Build against kernel header files. Change linux-2.4 to correct path for your system # CFLAGS = -fsigned-char -Wall -O2 -I./usr/src/linux-2.4/include ] Cheers, Bruce |
From: Guido G. <ag...@si...> - 2003-05-12 23:30:45
|
Hi Bruce, On Mon, May 12, 2003 at 05:04:25PM -0500, Bruce Allen wrote: > Oh my. > > This really isn't "the way it should be". Since for the various hard disk > ioctls() of course we want to use the headers/ioctls/data structures that > the KERNEL was built with not the ones that GCC was built with. Make that glibc not gcc. These headers usually come with the glibc-dev package. > These headers can often be found (Redhat distributions, anyway) under > /lib/modules/*/build. Is there any "standard location" for the actual > runnnig kernel's header files? Hmm...I think we can't expect to have the headers of the running kernel on the system at all (think about precompiled kernels that ship with the distribution - these are not necessarily the same headers as glibc was built with (and which therefor ended up in /usr/include)). Wouldn't we be safe if we'd expect kernel headers > 2.4? We could check /usr/include/linux/version.h for that in the Makefile (or with autoconf ;-) )[1]. I think we'll have to figure out the rest during runtime. Regards, -- Guido [1] this would additionally allow us to apply some magic to detect the best suitable kernel headers though (i.e. first check /lib/modules/..., then /usr/src/kernel-headers-2.4.*/, then /usr/include) quiet easily. |
From: Bruce A. <ba...@gr...> - 2003-05-13 14:15:04
|
Hi Guido, On Tue, 13 May 2003, Guido Guenther wrote: > Hi Bruce, > On Mon, May 12, 2003 at 05:04:25PM -0500, Bruce Allen wrote: > > Oh my. > > > > This really isn't "the way it should be". Since for the various hard disk > > ioctls() of course we want to use the headers/ioctls/data structures that > > the KERNEL was built with not the ones that GCC was built with. > Make that glibc not gcc. These headers usually come with the glibc-dev > package. Yes, of course, I meant glibc not gcc. > > These headers can often be found (Redhat distributions, anyway) under > > /lib/modules/*/build. Is there any "standard location" for the actual > > runnnig kernel's header files? > Hmm...I think we can't expect to have the headers of the running kernel > on the system at all (think about precompiled kernels that ship with the > distribution - these are not necessarily the same headers as glibc was > built with (and which therefor ended up in /usr/include)). Wouldn't we > be safe if we'd expect kernel headers > 2.4? We could check > /usr/include/linux/version.h for that in the Makefile (or with autoconf > ;-) )[1]. I think we'll have to figure out the rest during runtime. My feeling is that if the user doesn't have the kernel source tree (or at least the header files) on their system, then they should also be getting smartmontools precompiled, ideally on a system compatible with theirs. > [1] this would additionally allow us to apply some magic to detect the > best suitable kernel headers though (i.e. first check /lib/modules/..., > then /usr/src/kernel-headers-2.4.*/, then /usr/include) quiet easily. I think at least for the moment, nothing really needs to be done. The point is that if the appropriate definitions are missing at compile time, then the user will get one set of error messages. If the corresponding function call fails at run time, they'll get a different error message. In either case, the error message is clear enough and helpful enough that I don't think it's worth complicating the code base/install stuff further. [But I still think it might be worth adding the kernel patch URLs to the error messages.] Cheers, Bruce |