RE: RFC: Changes for PCI
On Wed, 27 Jun 2001, Jeff Garzik wrote: > However, I think the driver (only going by your description) would be > more correct to use a pointer to struct pci_dev. We have a token in the > kernel that is guaranteed 100% unique to any given PCI device: the > pointer to its struct pci_dev. Is it? With a hotplug device removed and another one added, isn't there a slight chance that the pci_dev pointer to the new device will get allocated in place of the old one? Vassilii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFC: Changes for PCI
On Wed, 27 Jun 2001, Jeff Garzik wrote: However, I think the driver (only going by your description) would be more correct to use a pointer to struct pci_dev. We have a token in the kernel that is guaranteed 100% unique to any given PCI device: the pointer to its struct pci_dev. Is it? With a hotplug device removed and another one added, isn't there a slight chance that the pci_dev pointer to the new device will get allocated in place of the old one? Vassilii - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: One more ZDNet article with BillG hammering Linux and Open Source.
> > simple source access. I don't know that anyone has ever > asked for the source > > code for Word. If they did, we would give it to them. But > it's not a typical > > request. > > So who wants to go ask for the source code to word then? I > mean we have > Bill's word that they will give it to us. If we go and do it, this will be automatically tagged as a "typical annoying request of an lkml subscriber". He only speaks about non-typical request. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: One more ZDNet article with BillG hammering Linux and Open Source.
simple source access. I don't know that anyone has ever asked for the source code for Word. If they did, we would give it to them. But it's not a typical request. So who wants to go ask for the source code to word then? I mean we have Bill's word that they will give it to us. If we go and do it, this will be automatically tagged as a typical annoying request of an lkml subscriber. He only speaks about non-typical request. :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: bzDisk compression Q; boot debug Q
> Question 2, apparently ramdisk uses gzip compression; the name of the > kernel from make bzImage seems to maybe refer to bzip2 compression. Is > the kernel image using gzip or bzip2 compression for bzImage? Would bzImage stands for "big zImage" - this is a format invented for kernels that don't fit into zImage. bzip2 has nothing to do with it :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: bzDisk compression Q; boot debug Q
Question 2, apparently ramdisk uses gzip compression; the name of the kernel from make bzImage seems to maybe refer to bzip2 compression. Is the kernel image using gzip or bzip2 compression for bzImage? Would bzImage stands for big zImage - this is a format invented for kernels that don't fit into zImage. bzip2 has nothing to do with it :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ethernet and pointopoint
> From: Adam [mailto:[EMAIL PROTECTED]] > Is there reason why I can't set pointopoint for ethernet? I have If your network cards & their drivers (both hosts) support full duplex operation, just enable it, and you're done. V. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ethernet and pointopoint
From: Adam [mailto:[EMAIL PROTECTED]] Is there reason why I can't set pointopoint for ethernet? I have If your network cards their drivers (both hosts) support full duplex operation, just enable it, and you're done. V. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kHTTPd hangs 2.4.5 boot when moduled
> I found that when kHTTPd is compiled as a module, kernel > 2.4.5 will hang ... > I run an Intel RH7.0 machine. Please note the following discrepancy between RH70 and the minimal required versions of the following 3 packages (I am ommitting others, like pci or reiserfs stuff, as these seem irrelevant to your case. See Docu*/Changes on 2.4.5 for details) package RH7.0 has...2.4.2 and on needs... util-linux 2.10m 2.10o modutils2.3.21 2.4.2 e2fsprogs 1.181.19 HTH, Vassilii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kHTTPd hangs 2.4.5 boot when moduled
I found that when kHTTPd is compiled as a module, kernel 2.4.5 will hang ... I run an Intel RH7.0 machine. Please note the following discrepancy between RH70 and the minimal required versions of the following 3 packages (I am ommitting others, like pci or reiserfs stuff, as these seem irrelevant to your case. See Docu*/Changes on 2.4.5 for details) package RH7.0 has...2.4.2 and on needs... util-linux 2.10m 2.10o modutils2.3.21 2.4.2 e2fsprogs 1.181.19 HTH, Vassilii - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Error Compiling Driver code:
1) Check the FAQ - http://www.tux.org/lkml/#s8 2) RH6.2 as it is doesn't come with all the newest tools versions needed for the 2.4.x kernels. See Documentation/versions. HTH, Vassilii > -Original Message- > Hi , > I am trying to compile a driver code in Red Hat 6.2 > which is already a working code, but I get the > following errors when i compile. > > /usr/src/linux/include/asm/smp.h:206: arguments given > to macro `hard_smp_processor_id' > [snip] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Error Compiling Driver code:
1) Check the FAQ - http://www.tux.org/lkml/#s8 2) RH6.2 as it is doesn't come with all the newest tools versions needed for the 2.4.x kernels. See Documentation/versions. HTH, Vassilii -Original Message- Hi , I am trying to compile a driver code in Red Hat 6.2 which is already a working code, but I get the following errors when i compile. /usr/src/linux/include/asm/smp.h:206: arguments given to macro `hard_smp_processor_id' [snip] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Makefile patch for cscope and saner Ctags
cscope: Minor stuff: 1) in cscope.files - I'd be replacing cscope.files with $@ within the rule - you don't need a yellow belt to know $@ within a Makefile 2) /bin/rm vs rm tags: Not going deep into it, I possibly should say here that hardwiring depth 5 is not the best thing probably - once someone extends down to 6, this place in the Makefile will for sure not be updated. You can make a loop here to max depth, which you can discover right here, rather than the current manually unrolled loop. In general, I am not a tags user in the kernel (sticking to local tags + global cscope), so I'd be happy if you and Pete could merge together your tags stuff. As for the ignore list, I don't see much of maintenance work there - and, if you guys think there is, maybe it is just possible to add Pete on the Kernel Build maintainers WRT to that file? Overall, IMHO, after you give it the last touch (maybe just dismissing my present letter :-) ) the cscope stuff is mature enough for going to KO & Co. (i.e. the kernel build guys); I don't consider myself a hardcore tags user to say so about the tags portion. Keith, what do you think? Vassilii > -Original Message- > From: Mark Frazer [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 31, 2001 4:45 PM > To: Khachaturov, Vassilii > Cc: Linux Kernel > Subject: Re: Makefile patch for cscope and saner Ctags > > > Khachaturov, Vassilii <[EMAIL PROTECTED]> > [01/05/31 15:00]: > > Don't forget to bug RH package maintainer on that. Whatever > > bugzilla submitted > > > I use source-built cscope v.15.1, and -k works for me here, > > works for me too! > > > WHY?! Isn't it better to put $(shell cat cscope.files) on > the list of > > I only have a yellow belt in makefile kungfu. These fancy > gnu make things > are relatively new to some of us... > > The latest patch is attached. include/linux/compile.h seems to get > built whenever I run make, so that's why I've excluded it > from the deps > for cscope.out. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [CHECKER] 2.4.5-ac4 non-init functions calling init functions
If you do implement such a thing, make sure that you don't mistakenly spot smth that gets exported to a non-kernel-tree driver, or smth that gets called by a non-__init, --- but not in the current kernel config! V. > -Original Message- > From: Dawson Engler [mailto:[EMAIL PROTECTED]] > checker to > > find functions which are only called from __init functions, but not > > marked __init themselves, you'd most likely find lots more > performance > > bugs of this kind. > > I haven't hacked this in --- I was waiting to get a feel for how > important the checker was before spending too much time on - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [CHECKER] 2.4.5-ac4 non-init functions calling init functions
If you do implement such a thing, make sure that you don't mistakenly spot smth that gets exported to a non-kernel-tree driver, or smth that gets called by a non-__init, --- but not in the current kernel config! V. -Original Message- From: Dawson Engler [mailto:[EMAIL PROTECTED]] checker to find functions which are only called from __init functions, but not marked __init themselves, you'd most likely find lots more performance bugs of this kind. I haven't hacked this in --- I was waiting to get a feel for how important the checker was before spending too much time on - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Makefile patch for cscope and saner Ctags
cscope: Minor stuff: 1) in cscope.files - I'd be replacing cscope.files with $@ within the rule - you don't need a yellow belt to know $@ within a Makefile 2) /bin/rm vs rm tags: Not going deep into it, I possibly should say here that hardwiring depth 5 is not the best thing probably - once someone extends down to 6, this place in the Makefile will for sure not be updated. You can make a loop here to max depth, which you can discover right here, rather than the current manually unrolled loop. In general, I am not a tags user in the kernel (sticking to local tags + global cscope), so I'd be happy if you and Pete could merge together your tags stuff. As for the ignore list, I don't see much of maintenance work there - and, if you guys think there is, maybe it is just possible to add Pete on the Kernel Build maintainers WRT to that file? Overall, IMHO, after you give it the last touch (maybe just dismissing my present letter :-) ) the cscope stuff is mature enough for going to KO Co. (i.e. the kernel build guys); I don't consider myself a hardcore tags user to say so about the tags portion. Keith, what do you think? Vassilii -Original Message- From: Mark Frazer [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 4:45 PM To: Khachaturov, Vassilii Cc: Linux Kernel Subject: Re: Makefile patch for cscope and saner Ctags Khachaturov, Vassilii [EMAIL PROTECTED] [01/05/31 15:00]: Don't forget to bug RH package maintainer on that. Whatever bugzilla submitted I use source-built cscope v.15.1, and -k works for me here, works for me too! WHY?! Isn't it better to put $(shell cat cscope.files) on the list of I only have a yellow belt in makefile kungfu. These fancy gnu make things are relatively new to some of us... The latest patch is attached. include/linux/compile.h seems to get built whenever I run make, so that's why I've excluded it from the deps for cscope.out. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Makefile patch for cscope and saner Ctags
> From: Mark Frazer [mailto:[EMAIL PROTECTED]] > Khachaturov, Vassilii <[EMAIL PROTECTED]> > > Great stuff. May I suggest adding -k to the cscope cmdline: > > + cscope -b -k -I include > > The cscope on my RH7.0 box didn't take -k! > [root@mjftest linux-2.4.5]# cscope -b -k -I include > cscope: unknown option: -k > [root@mjftest linux-2.4.5]# rpm -qf /usr/bin/cscope > cscope-13.0-6 > > weird, as man cscope documents -k's existence Don't forget to bug RH package maintainer on that. Whatever version they ship (I don't know, maybe 13 indeed didn't have -k) the mans and the binaries must be consistent. I use source-built cscope v.15.1, and -k works for me here, atop RH70 too. You can download it at http://cscope.sourceforge.net And, the cscope project guys are very responsive and willing to fix/implement things in their product. (BTW, anyone here knows how to submit a cvsweb patch/bug and get an answer? cvsweb at sourceforge seems dead, as well as cvsweb.org :-( ) You definitely want -k in the kernel Makefile to avoid irrelevant things from /usr/include!!! > I didn't see a way to add >>'ing the file to cscope.files > without greping > for it's entrance there already. So I've left the find ... method of > creating cscope.files. Sorry for being unclear. I meant: output the new find results into smth like .cscope.files, then compare (cmp -s) it to the current cscope.files, and replace the latter with it ONLY if there were diffs: > > The new .files should be created in a different file, and the old file > > shouldn't be replaced if there's no change. > cscope.out is now built by a shell command which does the checking > against the age of the files in cscope.files WHY?! Isn't it better to put $(shell cat cscope.files) on the list of cscope.out dependencies? Or, maybe better yet, cscope.make: cscope.files echo -n 'cscope.out: ' > .$@ cat $< >> .$@ mv .$@ $@ include cscope.make (or should it be `-include' here?) > Backout the old patch and try this one. [patch mostly snipped] > +.PHONY: scsope [patch mostly snipped] s/scs/csc/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Makefile patch for cscope and saner Ctags
Great stuff. May I suggest adding -k to the cscope cmdline: > + cscope -b -I include should become + cscope -b -k -I include Also, I think you should separate cscope.files creation into a different rule, and make the cscope target depend on it and on the files in it. (Like the stuff with .flags) The new .files should be created in a different file, and the old file shouldn't be replaced if there's no change. Lastly, you need to clean up. I think cscope.out should be cleaned up in the clean target, while the cscope.files should probably should only be cleaned on rmproper or such. Vassilii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Makefile patch for cscope and saner Ctags
Great stuff. May I suggest adding -k to the cscope cmdline: + cscope -b -I include should become + cscope -b -k -I include Also, I think you should separate cscope.files creation into a different rule, and make the cscope target depend on it and on the files in it. (Like the stuff with .flags) The new .files should be created in a different file, and the old file shouldn't be replaced if there's no change. Lastly, you need to clean up. I think cscope.out should be cleaned up in the clean target, while the cscope.files should probably should only be cleaned on rmproper or such. Vassilii - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Makefile patch for cscope and saner Ctags
From: Mark Frazer [mailto:[EMAIL PROTECTED]] Khachaturov, Vassilii [EMAIL PROTECTED] Great stuff. May I suggest adding -k to the cscope cmdline: + cscope -b -k -I include The cscope on my RH7.0 box didn't take -k! [root@mjftest linux-2.4.5]# cscope -b -k -I include cscope: unknown option: -k [root@mjftest linux-2.4.5]# rpm -qf /usr/bin/cscope cscope-13.0-6 weird, as man cscope documents -k's existence Don't forget to bug RH package maintainer on that. Whatever version they ship (I don't know, maybe 13 indeed didn't have -k) the mans and the binaries must be consistent. I use source-built cscope v.15.1, and -k works for me here, atop RH70 too. You can download it at http://cscope.sourceforge.net And, the cscope project guys are very responsive and willing to fix/implement things in their product. (BTW, anyone here knows how to submit a cvsweb patch/bug and get an answer? cvsweb at sourceforge seems dead, as well as cvsweb.org :-( ) You definitely want -k in the kernel Makefile to avoid irrelevant things from /usr/include!!! I didn't see a way to add 'ing the file to cscope.files without greping for it's entrance there already. So I've left the find ... method of creating cscope.files. Sorry for being unclear. I meant: output the new find results into smth like .cscope.files, then compare (cmp -s) it to the current cscope.files, and replace the latter with it ONLY if there were diffs: The new .files should be created in a different file, and the old file shouldn't be replaced if there's no change. cscope.out is now built by a shell command which does the checking against the age of the files in cscope.files WHY?! Isn't it better to put $(shell cat cscope.files) on the list of cscope.out dependencies? Or, maybe better yet, cscope.make: cscope.files echo -n 'cscope.out: ' .$@ cat $ .$@ mv .$@ $@ include cscope.make (or should it be `-include' here?) Backout the old patch and try this one. [patch mostly snipped] +.PHONY: scsope [patch mostly snipped] s/scs/csc/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.x: update for PCI vendor id 0x12d4
[Updated patch is in the end of this mail] Thanks, Mark! > submit patches as text in your message, since people want > to read them, and not waste time saving to a file, etc. > also, explain patches: who is vid 0x12d4, how did you get > the information, what does it effect, etc. BTW I noticed a funny thing: the file devlist.h I tried to patch doesn't always exist - as it gets built from the file pci.ids in the same directory. Noone complained on that :) What I don't understand is why pci_ids.h doesn't get generated from pci.ids as well. So, here's the new patch, sent along also to the pci.ids maintainer, along with the required info. 12d4 was DGM Then DGM was aquired by Comverse, and later the corresponding activities (and the same PCI boards manufacturing) went to Comverse spinoff Ulticom. So, in fact, Ulticom is just DGM under a different name and controlled by Comverse. I guess the PCI vendor registry should get updated at some point, but I thought it could be a great thing if Linux knew it ahead. (Currently reported by the PCI driver "DGM" is obsolete - such entity doesn't exist any more). Naturally, I have got this info being a Comverse employee. This patch only has effect on kernel PCI driver reporting on the 12d4 vendor ID. There is no Linux kernel code which supports the corresponding SS7 signalling boards. Kind regards, Vassilii --- /usr/src/linux-2.4.5/include/linux/pci_ids.hWed May 16 13:25:39 2001 +++ pci_ids.h Wed May 30 14:55:01 2001 @@ -1199,6 +1199,8 @@ #define PCI_VENDOR_ID_NVIDIA_SGS 0x12d2 #define PCI_DEVICE_ID_NVIDIA_SGS_RIVA128 0x0018 +#define PCI_VENDOR_ID_ULTICOM 0x12d4 /* Formerly DGM */ + #define PCI_SUBVENDOR_ID_CHASE_PCIFAST 0x12E0 #define PCI_SUBDEVICE_ID_CHASE_PCIFAST40x0031 #define PCI_SUBDEVICE_ID_CHASE_PCIFAST80x0021 --- /usr/src/linux-2.4.5/drivers/pci/pci.idsSat May 19 20:49:14 2001 +++ pci.ids Wed May 30 14:54:50 2001 @@ -3204,7 +3204,7 @@ 002c VTNT2 00a0 ITNT2 12d3 Vingmed Sound A/S -12d4 DGM +12d4 Ulticom (Formerly DGM) 12d5 Equator Technologies 12d6 Analogic Corp 12d7 Biotronic SRL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] 2.4.x: update for PCI vendor id 0x12d4
[Updated patch is in the end of this mail] Thanks, Mark! submit patches as text in your message, since people want to read them, and not waste time saving to a file, etc. also, explain patches: who is vid 0x12d4, how did you get the information, what does it effect, etc. BTW I noticed a funny thing: the file devlist.h I tried to patch doesn't always exist - as it gets built from the file pci.ids in the same directory. Noone complained on that :) What I don't understand is why pci_ids.h doesn't get generated from pci.ids as well. So, here's the new patch, sent along also to the pci.ids maintainer, along with the required info. 12d4 was DGMS. Then DGMS was aquired by Comverse, and later the corresponding activities (and the same PCI boards manufacturing) went to Comverse spinoff Ulticom. So, in fact, Ulticom is just DGMS under a different name and controlled by Comverse. I guess the PCI vendor registry should get updated at some point, but I thought it could be a great thing if Linux knew it ahead. (Currently reported by the PCI driver DGMS is obsolete - such entity doesn't exist any more). Naturally, I have got this info being a Comverse employee. This patch only has effect on kernel PCI driver reporting on the 12d4 vendor ID. There is no Linux kernel code which supports the corresponding SS7 signalling boards. Kind regards, Vassilii --- /usr/src/linux-2.4.5/include/linux/pci_ids.hWed May 16 13:25:39 2001 +++ pci_ids.h Wed May 30 14:55:01 2001 @@ -1199,6 +1199,8 @@ #define PCI_VENDOR_ID_NVIDIA_SGS 0x12d2 #define PCI_DEVICE_ID_NVIDIA_SGS_RIVA128 0x0018 +#define PCI_VENDOR_ID_ULTICOM 0x12d4 /* Formerly DGMS */ + #define PCI_SUBVENDOR_ID_CHASE_PCIFAST 0x12E0 #define PCI_SUBDEVICE_ID_CHASE_PCIFAST40x0031 #define PCI_SUBDEVICE_ID_CHASE_PCIFAST80x0021 --- /usr/src/linux-2.4.5/drivers/pci/pci.idsSat May 19 20:49:14 2001 +++ pci.ids Wed May 30 14:54:50 2001 @@ -3204,7 +3204,7 @@ 002c VTNT2 00a0 ITNT2 12d3 Vingmed Sound A/S -12d4 DGMS +12d4 Ulticom (Formerly DGMS) 12d5 Equator Technologies 12d6 Analogic Corp 12d7 Biotronic SRL - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.x: update for PCI vendor id 0x12d4
This is my 1st attempt to submit a patch here - flames welcome if I did smth wrong... It was done across 2.4.2, but it works safely against 2.4.4 as well. <> Kind regards, Vassilii pci_vendor_12d4.patch
[PATCH] 2.4.x: update for PCI vendor id 0x12d4
This is my 1st attempt to submit a patch here - flames welcome if I did smth wrong... It was done across 2.4.2, but it works safely against 2.4.4 as well. pci_vendor_12d4.patch Kind regards, Vassilii pci_vendor_12d4.patch
RE: VIA's Southbridge bug: Latest (pseudo-)patch
There is such a web page, and it's the .html version of the Hardware-HOWTO on any LDP mirror. Some distribution even print it and include with their booklets accompanying the installation CDs. Make sure you send case reports about any unsupported crap hardware there... > -Original Message- > What we need is a web page for listing crap hardware so less > people buy > it. > > Gerhard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: VIA's Southbridge bug: Latest (pseudo-)patch
There is such a web page, and it's the .html version of the Hardware-HOWTO on any LDP mirror. Some distribution even print it and include with their booklets accompanying the installation CDs. Make sure you send case reports about any unsupported crap hardware there... -Original Message- What we need is a web page for listing crap hardware so less people buy it. Gerhard - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Exporting symbols from a module.
If you have a local makefile with which you wish to build your module not linked under the kernel tree in the proper way, you still can "ride" on the master Makefile. This way one can eliminate the dependency on your particular machine kernel compilation options to be hardwired in the local Makefile. I.e., once you reconfigure the kernel, your driver will compile itself when you do a local "make" with the correct set of the new flags. This is what you can do on 2.2 (Makefile excerpt follows): EXTRA_CFLAGS := -DDEBUG -DLINUX -I/usr/src/foo/include MI_OBJS := your-module.o O_TARGET := your-module.o O_OBJS := your1.o your2.o # Reuse Linux kernel master makefile on this directory ifdef MAKING_MODULES include $(TOPDIR)/Rules.make else all:: cd '/usr/src/linux' && make modules SUBDIRS=$(PWD) endif In 2.4 the syntax is different. Rename MI_OBJS to obj-m and O_OBJS to obj-y to achieve the same goal there: obj-m := your-module.o O_TARGET := your-module.o obj-y := your1.o your2.o HTH, Vassilii > -Original Message- > From: Anders Peter Fugmann [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 17, 2001 12:51 PM > To: Andreas Dilger > Cc: linux-kernel > Subject: Re: Exporting symbols from a module. > > > Resolved. > > I just looked at what the kernel did whne compiling a module that > exported some symbols, and discovered that I needed > to set CFLAGS to: > > -D__KERNEL__ -I$/usr/src/linux) -Wall -Wstrict-prototypes \ > -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe \ > -DMODULE -DMODVERSIONS -include \ > /usr/src/linux/modversions.h > > Now all works correctly, and I can load my modules. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ctags
I use cscope instead, and vim's front-end to it. (Emacs fans: XEmacs has a similar support, see cscope page on sourceforge). Much more powerful than plain tags, because it allows also things like "where are all the calls to this function", but you still can jump about with ^T/^] At top level of the kernel source tree (/usr/src/linux) do find . -name '*.[hc]' -print > cscope.files cscope -b -k -I/usr/src/linux/include In the .vimrc used for kernel editing, do: cscope add /usr/src/linux/cscope.out /usr/src/linux set cstag And do :help cscope to see what this thing is about... Or, for a quick start, just do :cs See also cscope on sourceforge. HTH, Vassilii > -Original Message- > From: Blesson Paul [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 17, 2001 4:10 AM > To: [EMAIL PROTECTED] > Subject: ctags > > > > find -name '*.[ch]' | ctag -L- & > echo "set tags-tags">>.vimrc > > Hi >Thanks for the reply. To get the definition of the > functions above is enough. Now if there are more than one > definition of the > same function how to get all the definitions > > by > Blesson Paul > > > Get free email and a permanent address at > http://www.netaddress.com/?N=1 > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ctags
I use cscope instead, and vim's front-end to it. (Emacs fans: XEmacs has a similar support, see cscope page on sourceforge). Much more powerful than plain tags, because it allows also things like where are all the calls to this function, but you still can jump about with ^T/^] At top level of the kernel source tree (/usr/src/linux) do find . -name '*.[hc]' -print cscope.files cscope -b -k -I/usr/src/linux/include In the .vimrc used for kernel editing, do: cscope add /usr/src/linux/cscope.out /usr/src/linux set cstag And do :help cscope to see what this thing is about... Or, for a quick start, just do :cs See also cscope on sourceforge. HTH, Vassilii -Original Message- From: Blesson Paul [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 17, 2001 4:10 AM To: [EMAIL PROTECTED] Subject: ctags find -name '*.[ch]' | ctag -L- echo set tags-tags.vimrc Hi Thanks for the reply. To get the definition of the functions above is enough. Now if there are more than one definition of the same function how to get all the definitions by Blesson Paul Get free email and a permanent address at http://www.netaddress.com/?N=1 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Exporting symbols from a module.
If you have a local makefile with which you wish to build your module not linked under the kernel tree in the proper way, you still can ride on the master Makefile. This way one can eliminate the dependency on your particular machine kernel compilation options to be hardwired in the local Makefile. I.e., once you reconfigure the kernel, your driver will compile itself when you do a local make with the correct set of the new flags. This is what you can do on 2.2 (Makefile excerpt follows): EXTRA_CFLAGS := -DDEBUG -DLINUX -I/usr/src/foo/include MI_OBJS := your-module.o O_TARGET := your-module.o O_OBJS := your1.o your2.o # Reuse Linux kernel master makefile on this directory ifdef MAKING_MODULES include $(TOPDIR)/Rules.make else all:: cd '/usr/src/linux' make modules SUBDIRS=$(PWD) endif In 2.4 the syntax is different. Rename MI_OBJS to obj-m and O_OBJS to obj-y to achieve the same goal there: obj-m := your-module.o O_TARGET := your-module.o obj-y := your1.o your2.o HTH, Vassilii -Original Message- From: Anders Peter Fugmann [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 17, 2001 12:51 PM To: Andreas Dilger Cc: linux-kernel Subject: Re: Exporting symbols from a module. Resolved. I just looked at what the kernel did whne compiling a module that exported some symbols, and discovered that I needed to set CFLAGS to: -D__KERNEL__ -I$/usr/src/linux) -Wall -Wstrict-prototypes \ -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe \ -DMODULE -DMODVERSIONS -include \ /usr/src/linux/modversions.h Now all works correctly, and I can load my modules. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ((struct pci_dev*)dev)->resource[...].start
Jeff,
Many thanks for the clarifications.
> From: Jeff Garzik
> "Khachaturov, Vassilii" wrote:
[snip]
> > bootup, the mapping of the PCI base address registers to
> virtual memory will
> > remain the same (just as seen in /proc/pci, and as
> reflected in )? If
> > not, is there a way to freeze it for the time I want to access it?
>
> This is not a safe assumption, because the OS may reprogram
> the PCI BARs
> at certain times. The rule is: ALWAYS read from
> dev->resource[] unless
> you are a bus driver (PCI bridges, for example, need to assign
> resources).
[snip]
I am not a bus driver, and I do call pci_enable_device once my device gets
probed and recognized by my driver. I always read from dev->resource[].
But what are the "certain times" you've mentioned? What is the scope
within which I know the BARs didn't change?
> Finally, make sure to use pci_resource_{start,end,len,flags} macros to
> make your core more portable and future-proof.
I didn't use the macros - now I do, thanks for the tip!
> > 2) (Basically, the question is "Do I understand
> Documentation/IO-mapping.txt
> > right?")
> > PCI memory, whenever IO type or memory type, can not be
> dereferenced but
> > should be accessed with readb() etc. On i386, PCI mem
> (memory type) can be
> > accessed by direct pointer access, but this is not portable.
>
> We will yell at you mightily if you directly access PCI mem with a
> pointer. As you say it only works on i386 -- but IIRC since
Right now I am porting a driver to Linux which has so much i386 things in it
(esp. byte order stuff). So far I haven't spoilt it with PCI i386 hacks
though...
> ioremap is
> required, we are perfectly free to change or modify that assumption.
> For example ioremap might [have to] care about whether or not
> a pci mem
> region is prefetchable.
A really silly q. (I don't quite understand the Linux internals yet):
Is ioremap() needed (in general vs. i386) for memory type PCI memory too,
or only for IO type?
(In case the default size of the region associated with a BAR is fine with
me?)
Thanks,
Vassilii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
((struct pci_dev*)dev)->resource[...].start
Can someone please confirm if my assumptions below are correct: 1) Unless someone specifically tampered with my driver's device since the OS bootup, the mapping of the PCI base address registers to virtual memory will remain the same (just as seen in /proc/pci, and as reflected in )? If not, is there a way to freeze it for the time I want to access it? 2) (Basically, the question is "Do I understand Documentation/IO-mapping.txt right?") PCI memory, whenever IO type or memory type, can not be dereferenced but should be accessed with readb() etc. On i386, PCI mem (memory type) can be accessed by direct pointer access, but this is not portable. Kind regards, Vassilii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: LANANA: To Pending Device Number Registrants
Well, even if you spank the future violators, what about the current overlaps? E.g., the CD-ROM ioctls are overlapping with the STREAMS ioctls (the latter ones used by LiS and honored by glibc). V. > -Original Message- > From: H. Peter Anvin [mailto:[EMAIL PROTECTED]] > Alan Cox wrote: > > > > > 1. is of course a problem in itself. Someone who creates > overlapping > > > ioctls should be spanked, hard. > > > > No argument there. But there is no LANANA ioctl body > > > > I though Michael Chastain was maintaining this set. No, we > haven't made > it an official LANANA function, mostly because I didn't want to push. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: IRQ usage for PCI devices, Kernel 2.4.4
If your PCI devices advertised they don't mind sharing the IRQs with each other, ignore it if they're really capable of it. Otherwise, you'll probably have to force one of the drivers and/or the bios to make them use separate ones. > -Original Message- > From: Joachim Backes [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 16, 2001 1:46 AM > To: LINUX Kernel > Subject: IRQ usage for PCI devices, Kernel 2.4.4 > > > Hi, > > sometimes the following messages appear in /var/log/messages: > > May 13 14:24:41 sunny kernel: PCI: Found IRQ 10 for > device 00:0e.0 > May 13 14:24:41 sunny kernel: PCI: The same IRQ used > for device 00:0a.0 > > "0e" is my PCI sound card, and "0a" is my PCI ethernet card. > The messages apppear in > the following environment: I send from another linux machine > (per ssh) a command > wich plays some sound on my sound card, therefore the eth0 > event and the sound > event occur at almost the same time. > > Question: Can I ignore these messages, or is there any buggy > behaviour? > > Regards > > > Joachim Backes > > -- > > Joachim Backes <[EMAIL PROTECTED]> | Univ. of Kaiserslautern > Computer Center, High Performance Computing | Phone: > +49-631-205-2438 > D-67653 Kaiserslautern, PO Box 3049, Germany | Fax: > +49-631-205-3056 > -+ > WWW: http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html > > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: LANANA: To Pending Device Number Registrants
Well, even if you spank the future violators, what about the current overlaps? E.g., the CD-ROM ioctls are overlapping with the STREAMS ioctls (the latter ones used by LiS and honored by glibc). V. -Original Message- From: H. Peter Anvin [mailto:[EMAIL PROTECTED]] Alan Cox wrote: 1. is of course a problem in itself. Someone who creates overlapping ioctls should be spanked, hard. No argument there. But there is no LANANA ioctl body I though Michael Chastain was maintaining this set. No, we haven't made it an official LANANA function, mostly because I didn't want to push. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: IRQ usage for PCI devices, Kernel 2.4.4
If your PCI devices advertised they don't mind sharing the IRQs with each other, ignore it if they're really capable of it. Otherwise, you'll probably have to force one of the drivers and/or the bios to make them use separate ones. -Original Message- From: Joachim Backes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 1:46 AM To: LINUX Kernel Subject: IRQ usage for PCI devices, Kernel 2.4.4 Hi, sometimes the following messages appear in /var/log/messages: May 13 14:24:41 sunny kernel: PCI: Found IRQ 10 for device 00:0e.0 May 13 14:24:41 sunny kernel: PCI: The same IRQ used for device 00:0a.0 0e is my PCI sound card, and 0a is my PCI ethernet card. The messages apppear in the following environment: I send from another linux machine (per ssh) a command wich plays some sound on my sound card, therefore the eth0 event and the sound event occur at almost the same time. Question: Can I ignore these messages, or is there any buggy behaviour? Regards Joachim Backes -- Joachim Backes [EMAIL PROTECTED] | Univ. of Kaiserslautern Computer Center, High Performance Computing | Phone: +49-631-205-2438 D-67653 Kaiserslautern, PO Box 3049, Germany | Fax: +49-631-205-3056 -+ WWW: http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
((struct pci_dev*)dev)-resource[...].start
Can someone please confirm if my assumptions below are correct: 1) Unless someone specifically tampered with my driver's device since the OS bootup, the mapping of the PCI base address registers to virtual memory will remain the same (just as seen in /proc/pci, and as reflected in subj)? If not, is there a way to freeze it for the time I want to access it? 2) (Basically, the question is Do I understand Documentation/IO-mapping.txt right?) PCI memory, whenever IO type or memory type, can not be dereferenced but should be accessed with readb() etc. On i386, PCI mem (memory type) can be accessed by direct pointer access, but this is not portable. Kind regards, Vassilii - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ((struct pci_dev*)dev)-resource[...].start
Jeff,
Many thanks for the clarifications.
From: Jeff Garzik
Khachaturov, Vassilii wrote:
[snip]
bootup, the mapping of the PCI base address registers to
virtual memory will
remain the same (just as seen in /proc/pci, and as
reflected in subj)? If
not, is there a way to freeze it for the time I want to access it?
This is not a safe assumption, because the OS may reprogram
the PCI BARs
at certain times. The rule is: ALWAYS read from
dev-resource[] unless
you are a bus driver (PCI bridges, for example, need to assign
resources).
[snip]
I am not a bus driver, and I do call pci_enable_device once my device gets
probed and recognized by my driver. I always read from dev-resource[].
But what are the certain times you've mentioned? What is the scope
within which I know the BARs didn't change?
Finally, make sure to use pci_resource_{start,end,len,flags} macros to
make your core more portable and future-proof.
I didn't use the macros - now I do, thanks for the tip!
2) (Basically, the question is Do I understand
Documentation/IO-mapping.txt
right?)
PCI memory, whenever IO type or memory type, can not be
dereferenced but
should be accessed with readb() etc. On i386, PCI mem
(memory type) can be
accessed by direct pointer access, but this is not portable.
We will yell at you mightily if you directly access PCI mem with a
pointer. As you say it only works on i386 -- but IIRC since
Right now I am porting a driver to Linux which has so much i386 things in it
(esp. byte order stuff). So far I haven't spoilt it with PCI i386 hacks
though...
ioremap is
required, we are perfectly free to change or modify that assumption.
For example ioremap might [have to] care about whether or not
a pci mem
region is prefetchable.
A really silly q. (I don't quite understand the Linux internals yet):
Is ioremap() needed (in general vs. i386) for memory type PCI memory too,
or only for IO type?
(In case the default size of the region associated with a BAR is fine with
me?)
Thanks,
Vassilii
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t
Chris, thanks for your reply. My case is exactly when copying has to be made, hence the awareness of the user/kernel uid/gid "personalities". I am trying to understand what's the cleanest coding that would allow 1) user code to just use uid/gid for interfacing the driver control structures 2) driver code to read/write the corresponding structure fields with minimum awareness of the actual difference between kernel and user uid_t/gid_t layout. 3) all the messy adaptation confined as much as possible at the types declaration (in the header included by both) 4) (2) & (3) should take into acct different platforms. Right now, I allocate a uid_t/gid_t in the corresponding structure field at the user level, and add arch-dependent padding in the kernel; and I had to wrap the kernel-level access to these fields with special encoder/decoder macros as long as user<->kernel interaction is taking place :-( - see my orig. post for details. My driver code doesn't use the __kernel types directly, but in the wrapping header macros I preferred those because I was explicitly defining the padding logic, and was treating difference betw. user and kernel-level uids and gids. V. -Original Message- From: Chris Wing [mailto:[EMAIL PROTECTED]] Vassilii: __kernel_uid_t is my fault. The names are confusing, but uid_t and gid_t are NOT supposed to be different in kernel and user space. [snip] Kernel code should always use uid_t as a type, except when copying data between user and kernel space. In that case, just make sure that whatever data structure you use is big enough to contain a Linux uid_t. (as of 2.4, Linux uses 32-bit uid_t on all platforms) All new interfaces to user space should use 32-bit uids, i.e. type unsigned int. Don't use __kernel_uid_t at all in new code. The name is basically there only because the older libc5 C library included the kernel headers and we have to preserve it so that programs still compile on these old systems. if you look inside /include/linux/types.h, this is made explicit: #ifdef __KERNEL__ typedef __kernel_uid32_tuid_t; [snip] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t
I had to communicate uid/gid from an application down to a driver, and discovered that uid and gid in user space are different from those in kernel space. I am porting both the driver and the app from platforms where uid and gid in userland don't differ from their counterparts down in the kernel. What would be the appealing portable way (across all Linux platforms with their different byteorders) to declare a type for such user/kernel interface? Right now I am using smth that I feel is ugly a bit, to declare fields of a transparent type: /* MY uid_t/gid_t - shared types for user and kernel space */ #if defined(LINUX) && defined (__KERNEL__) #ifdef CONFIG_X86 # define my_uid_t(var_name,pad_name) \ __kernel_uid_t var_name; unsigned short pad_name # define my_gid_t(var_name,pad_name) \ __kernel_gid_t var_name; unsigned short pad_name #else /* other archs I need to support, with arch-specific alignment */ ... #endif #else /* Not Linux kernel - uid/gid same in user/kernel space */ # define my_uid_t(var_name,pad_name) uid_t var_name # define my_gid_t(var_name,pad_name) gid_t var_name #endif and also I need special functions to set/get the var+ padding in kernel to make sure that the padding is set to 0/-1 according to the sign of the var, each time I get smth from/send smth to the userland from the kernel. Is there a known pattern for doing things like this? Maybe some special macros just for gid/uid specifically? I am just feeling that I try reinvent a wheel here... Kind regards, Vassilii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t
I had to communicate uid/gid from an application down to a driver, and discovered that uid and gid in user space are different from those in kernel space. I am porting both the driver and the app from platforms where uid and gid in userland don't differ from their counterparts down in the kernel. What would be the appealing portable way (across all Linux platforms with their different byteorders) to declare a type for such user/kernel interface? Right now I am using smth that I feel is ugly a bit, to declare fields of a transparent type: /* MY uid_t/gid_t - shared types for user and kernel space */ #if defined(LINUX) defined (__KERNEL__) #ifdef CONFIG_X86 # define my_uid_t(var_name,pad_name) \ __kernel_uid_t var_name; unsigned short pad_name # define my_gid_t(var_name,pad_name) \ __kernel_gid_t var_name; unsigned short pad_name #else /* other archs I need to support, with arch-specific alignment */ ... #endif #else /* Not Linux kernel - uid/gid same in user/kernel space */ # define my_uid_t(var_name,pad_name) uid_t var_name # define my_gid_t(var_name,pad_name) gid_t var_name #endif and also I need special functions to set/get the var+ padding in kernel to make sure that the padding is set to 0/-1 according to the sign of the var, each time I get smth from/send smth to the userland from the kernel. Is there a known pattern for doing things like this? Maybe some special macros just for gid/uid specifically? I am just feeling that I try reinvent a wheel here... Kind regards, Vassilii - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t
Chris, thanks for your reply. My case is exactly when copying has to be made, hence the awareness of the user/kernel uid/gid personalities. I am trying to understand what's the cleanest coding that would allow 1) user code to just use uid/gid for interfacing the driver control structures 2) driver code to read/write the corresponding structure fields with minimum awareness of the actual difference between kernel and user uid_t/gid_t layout. 3) all the messy adaptation confined as much as possible at the types declaration (in the header included by both) 4) (2) (3) should take into acct different platforms. Right now, I allocate a uid_t/gid_t in the corresponding structure field at the user level, and add arch-dependent padding in the kernel; and I had to wrap the kernel-level access to these fields with special encoder/decoder macros as long as user-kernel interaction is taking place :-( - see my orig. post for details. My driver code doesn't use the __kernel types directly, but in the wrapping header macros I preferred those because I was explicitly defining the padding logic, and was treating difference betw. user and kernel-level uids and gids. V. -Original Message- From: Chris Wing [mailto:[EMAIL PROTECTED]] Vassilii: __kernel_uid_t is my fault. The names are confusing, but uid_t and gid_t are NOT supposed to be different in kernel and user space. [snip] Kernel code should always use uid_t as a type, except when copying data between user and kernel space. In that case, just make sure that whatever data structure you use is big enough to contain a Linux uid_t. (as of 2.4, Linux uses 32-bit uid_t on all platforms) All new interfaces to user space should use 32-bit uids, i.e. type unsigned int. Don't use __kernel_uid_t at all in new code. The name is basically there only because the older libc5 C library included the kernel headers and we have to preserve it so that programs still compile on these old systems. if you look inside /include/linux/types.h, this is made explicit: #ifdef __KERNEL__ typedef __kernel_uid32_tuid_t; [snip] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Detecting Red Hat builds ?
For a RH7.x, at least, there is the /boot/kernel.h file generated on bootup, and the RH kernel headers include it somewhere. You can see if the corresponding symbols (coming from it) are defined, and assume redhat than. You might consider using passing -dM down to the preprocessor with the standard driver includes preamble, and look in the preprocessed output for a good clue - it may well be that there is some other redhat-specific string somewhere defined. I guess you will find smth if you egrep -i (rh|redhat). HTH, Vassilii -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 12:25 PM To: [EMAIL PROTECTED] Subject: Detecting Red Hat builds ? Hi, How can I determine if the build my device driver is being compiled under is a standard kernel.org one or a Red Hat one ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Detecting Red Hat builds ?
For a RH7.x, at least, there is the /boot/kernel.h file generated on bootup, and the RH kernel headers include it somewhere. You can see if the corresponding symbols (coming from it) are defined, and assume redhat than. You might consider using passing -dM down to the preprocessor with the standard driver includes preamble, and look in the preprocessed output for a good clue - it may well be that there is some other redhat-specific string somewhere defined. I guess you will find smth if you egrep -i (rh|redhat). HTH, Vassilii -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 12:25 PM To: [EMAIL PROTECTED] Subject: Detecting Red Hat builds ? Hi, How can I determine if the build my device driver is being compiled under is a standard kernel.org one or a Red Hat one ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: PCMCIA IDE flash problem found
Why did not you take care of the request_region() call and just disabled it?
The ports will be considered free by the system, and another device might
grab them later on!
Vassilii
-Original Message-
From: Pavel Machek [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 08, 2001 8:14 AM
To: kernel list
Subject: PCMCIA IDE flash problem found
Hi!
2.4.[123] changed name of ide-cs module, which means your pcmcia setup
breaks... This is how to undo the damage. Works for me, do *not* apply
into anything official.
Pavel
--- clean/drivers/ide/ide-cs.c Sun Apr 1 00:23:29 2001
+++ linux/drivers/ide/ide-cs.c Tue May 8 14:06:09 2001
@@ -95,7 +96,7 @@
static int ide_event(event_t event, int priority,
event_callback_args_t *args);
-static dev_info_t dev_info = "ide-cs";
+static dev_info_t dev_info = "ide_cs";
static dev_link_t *ide_attach(void);
static void ide_detach(dev_link_t *);
@@ -388,9 +389,12 @@
MOD_DEC_USE_COUNT;
}
+#if 0
request_region(link->io.BasePort1, link->io.NumPorts1,"ide-cs");
if (link->io.NumPorts2)
request_region(link->io.BasePort2, link->io.NumPorts2,"ide-cs");
+#endif
+printk("Should call request_region\n");
info->ndev = 0;
link->dev = NULL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
kmalloc(..., GFP_ATOMIC) buffers contiguous - hence suitable for PCI DMA?
Hi folks! (I have looked up in the archive the linux-kernel threads for kwds "DMA, contiguous, address" before writing this mail, and read the corresponding threads.) I am trying to port some driver to Linux2.4/i386. I have just read the "Linux device drivers" book by A.Rubini, and this is what he says there in Ch.13 "Mmap & DMA", on the GFP_DMA allocator flag: "The kernel guarantees that DMA-capable buffers have 2 features. 1st, the phys. addrs must be conseccutive when get_free_page() returns > 1 page (but this is always true, indep. of GFP_DMA, because the kernel arranges free memory in clusters of consecutive pages). And second, when GFP_DMA is set, the kernel guarantees that only addrs lower than MAX_DMA_ADDRESS are returned. The macro MAX_DMA_ADDRESS is set to 16MB on the PC, to deal with the ISA [...]. As far as PCI is concerned, there's no MAX_DMA_ADDRESS limit, and a PCI dev. driver should avoid setting GFP_DMA when allocating its buffers." Is this really still true at kernels 2.2 and on? (The book refers to 2.1.43 as to the most modern version as of the time of its writing) I.e., can I just assume a buffer which I know to have been successfully allocated with just a kmalloc(..., GFP_ATOMIC) will be physically contiguous and hence suitable for PCI DMA? I tried to understand the corresponding code path in mm/slab.c, but failed to come up with a 100%-assuring opinion out of it. The driver and the device at present are not oriented for doing scatter-gather. TIA for any possible help, Vassilii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kmalloc(..., GFP_ATOMIC) buffers contiguous - hence suitable for PCI DMA?
Hi folks! (I have looked up in the archive the linux-kernel threads for kwds DMA, contiguous, address before writing this mail, and read the corresponding threads.) I am trying to port some driver to Linux2.4/i386. I have just read the Linux device drivers book by A.Rubini, and this is what he says there in Ch.13 Mmap DMA, on the GFP_DMA allocator flag: The kernel guarantees that DMA-capable buffers have 2 features. 1st, the phys. addrs must be conseccutive when get_free_page() returns 1 page (but this is always true, indep. of GFP_DMA, because the kernel arranges free memory in clusters of consecutive pages). And second, when GFP_DMA is set, the kernel guarantees that only addrs lower than MAX_DMA_ADDRESS are returned. The macro MAX_DMA_ADDRESS is set to 16MB on the PC, to deal with the ISA [...]. As far as PCI is concerned, there's no MAX_DMA_ADDRESS limit, and a PCI dev. driver should avoid setting GFP_DMA when allocating its buffers. Is this really still true at kernels 2.2 and on? (The book refers to 2.1.43 as to the most modern version as of the time of its writing) I.e., can I just assume a buffer which I know to have been successfully allocated with just a kmalloc(..., GFP_ATOMIC) will be physically contiguous and hence suitable for PCI DMA? I tried to understand the corresponding code path in mm/slab.c, but failed to come up with a 100%-assuring opinion out of it. The driver and the device at present are not oriented for doing scatter-gather. TIA for any possible help, Vassilii - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: PCMCIA IDE flash problem found
Why did not you take care of the request_region() call and just disabled it? The ports will be considered free by the system, and another device might grab them later on! Vassilii -Original Message- From: Pavel Machek [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 8:14 AM To: kernel list Subject: PCMCIA IDE flash problem found Hi! 2.4.[123] changed name of ide-cs module, which means your pcmcia setup breaks... This is how to undo the damage. Works for me, do *not* apply into anything official. Pavel --- clean/drivers/ide/ide-cs.c Sun Apr 1 00:23:29 2001 +++ linux/drivers/ide/ide-cs.c Tue May 8 14:06:09 2001 @@ -95,7 +96,7 @@ static int ide_event(event_t event, int priority, event_callback_args_t *args); -static dev_info_t dev_info = ide-cs; +static dev_info_t dev_info = ide_cs; static dev_link_t *ide_attach(void); static void ide_detach(dev_link_t *); @@ -388,9 +389,12 @@ MOD_DEC_USE_COUNT; } +#if 0 request_region(link-io.BasePort1, link-io.NumPorts1,ide-cs); if (link-io.NumPorts2) request_region(link-io.BasePort2, link-io.NumPorts2,ide-cs); +#endif +printk(Should call request_region\n); info-ndev = 0; link-dev = NULL; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
