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
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?
> > 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
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
> 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
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
> 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
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
> 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
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
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
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
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]:
>
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]]
>
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]]
[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
> 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 linu
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
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
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
[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
[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
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
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
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
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
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
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
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
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
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
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
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:
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
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:
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
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,
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
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)
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
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
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)
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
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
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:
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
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
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:
48 matches
Mail list logo
