devices as well. I tested this patch by looking
through my QX3 microscope under XawTV, which did not work without this
change.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630
The "ld" program in binutils-2.10.1.0.7 and in
binutils-2.10.91.0.2 now requires "--oformat" instead of "-oformat".
This breaks linux-2.4.2-pre3/arch/i386/boot/Makefile. I have attached
the fix below. I am running a kernel built with this updated
The "ld" program in binutils-2.10.1.0.7 and in
binutils-2.10.91.0.2 now requires "--oformat" instead of "-oformat".
This breaks linux-2.4.2-pre3/arch/i386/boot/Makefile. I have attached
the fix below. I am running a kernel built with this updated
declarations in PCI
drivers that are currently marked as __initdata back to __devinitdata.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States
declarations in PCI
drivers that are currently marked as __initdata back to __devinitdata.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States
ularity) -1) & ~mask" will always
fail on x86+gcc if bit_granularity == 32, because the value of 1<<32
on x86 + gcc-2.95.2 is 1, not 0. The value of 1<= bitsizeof(result), so we should not do this anyhow.
Anyhow, here is a patch that should fix the
that md_setup() is compiled only when md.c
is not a module. Here is the patch.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
that md_setup() is compiled only when md.c
is not a module. Here is the patch.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
y) -1) ~mask" will always
fail on x86+gcc if bit_granularity == 32, because the value of 132
on x86 + gcc-2.95.2 is 1, not 0. The value of 1n is not defined
in ANSI C when n = bitsizeof(result), so we should not do this anyhow.
Anyhow, here is a patch that should fix the problem.
ld provide a much less disruptive
migration path for adoption across firewalls that drop these packets.
Far more sites could then safely activate this feature without limiting
the hosts that they can reach.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL
ld provide a much less disruptive
migration path for adoption across firewalls that drop these packets.
Far more sites could then safely activate this feature without limiting
the hosts that they can reach.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL
, gets a compilation error. The following patch fix the problem
by stretching an earlier "#ifdef __KERNEL__...#endif" area to cover
the acpi_get_rsdp_ptr declaration.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
such as
acpid, gets a compilation error. The following patch fix the problem
by stretching an earlier "#ifdef __KERNEL__...#endif" area to cover
the acpi_get_rsdp_ptr declaration.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED]
to be only USB driver that
was missed: drivers/usb/serial/mct_u232.c. This patch fixes the problem.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l
to be only USB driver that
was missed: drivers/usb/serial/mct_u232.c. This patch fixes the problem.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l
is the prefered name, so here is a patch
fixing include/asm-i386/xor.h.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408
is the prefered name, so here is a patch
fixing include/asm-i386/xor.h.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408
>From: "David L. Parsley" <[EMAIL PROTECTED]>
>Linus Torvalds wrote:
>> On Sat, 6 Jan 2001, Adam J. Richter wrote:
>> >
>> > This sounds like a bug that I posted a fix for a long time ago.
>> > cramfs calls bforget on the superbloc
From: "David L. Parsley" [EMAIL PROTECTED]
Linus Torvalds wrote:
On Sat, 6 Jan 2001, Adam J. Richter wrote:
This sounds like a bug that I posted a fix for a long time ago.
cramfs calls bforget on the superblock area, destroying that block of
the ramdisk, even when t
on that hardware, and this minor addition to i386_ksyms.c
was the only change that I had to make to get a clean build. Hooray!
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630
on that hardware, and this minor addition to i386_ksyms.c
was the only change that I had to make to get a clean build. Hooray!
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630
(I think that is just ramdisk blocks), but that would waste memory,
because we really can release blocks from things like truncating
or unlinking files.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California
changes.
So far, I can tell you that reverting the linux/mm subdirectory to
its 2.4.0-prerelease contents had no effect. I will let you know
if I diagnose or fix the problem, as I think you may be experiencing
the same problem.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite
changes.
So far, I can tell you that reverting the linux/mm subdirectory to
its 2.4.0-prerelease contents had no effect. I will let you know
if I diagnose or fix the problem, as I think you may be experiencing
the same problem.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite
ste memory,
because we really can release blocks from things like truncating
or unlinking files.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i
: acpi_ns_execute_control_method
would not would return without releasing the
ACPI_MTX_NAMESPACE mutex if acpi_ns_get_attached_obect
returned NULL.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED
: acpi_ns_execute_control_method
would not would return without releasing the
ACPI_MTX_NAMESPACE mutex if acpi_ns_get_attached_obect
returned NULL.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED
e 386's have
already obscelesced from those applications, and still would have, even
with FP emulation in assembly.
It's not my call to make, and I think we will follow the stock
kernels' drivers/char/drm even if it continues this weirdness, but I
certainly hope this duplicatio
, but
if there is not some information that I have missed about this issue,
then I sure hope that the drm maintainers will see the light or, if not,
that Linus overrules the drm maintainers if necessary and integrates a
patch like the one I posted and just deletes those comments from
drivers/char/
takes advantage of the new style
Makefile rules to achieve this end. I think it basically is the
correct approach, although I have not yet tested compilation into
the kernel.
Any testing and feedback would be appreciated.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd
this change
should be regarded as a stylistic cleanup even if we are not forced
to make the change.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l
if the
delays really need to be this long.
Anyhow, I think we should try to resolve the __bad_udelay
problems somehow by, say, linux-2.4.0-prerelease79. :-)
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San
I will explore this more tomorrow, but I have been exploring
this problem on and off for three days, so I thought I ought to
mention it on linux-kernel.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose
I will explore this more tomorrow, but I have been exploring
this problem on and off for three days, so I thought I ought to
mention it on linux-kernel.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose
if the
delays really need to be this long.
Anyhow, I think we should try to resolve the __bad_udelay
problems somehow by, say, linux-2.4.0-prerelease79. :-)
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San
s seems to be the standard, so this change
should be regarded as a stylistic cleanup even if we are not forced
to make the change.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-
takes advantage of the new style
Makefile rules to achieve this end. I think it basically is the
correct approach, although I have not yet tested compilation into
the kernel.
Any testing and feedback would be appreciated.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd
' drivers/char/drm even if it continues this weirdness, but I
certainly hope this duplication of libdrm in every module will be dropped.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408
It looks like 2.4.0-test13-pre6 contains a partially applied
patch in net/atm/lec.c. It adds references to the symbols
prepare_etherdev and publish_netdev, which are not defined anywhere.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED
It looks like 2.4.0-test13-pre6 contains a partially applied
patch in net/atm/lec.c. It adds references to the symbols
prepare_etherdev and publish_netdev, which are not defined anywhere.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED
ders to sound the alarm
if I botched the patch.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 &
s to sound the alarm
if I botched the patch.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 &quo
peded
from doing so by this change.
Anyhow, I thought I should post this suggestion to see if
anyone has any objections, better ideas, improvements or comments.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
peded
from doing so by this change.
Anyhow, I thought I should post this suggestion to see if
anyone has any objections, better ideas, improvements or comments.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
1GHz
CPU. So, more instructions per time slice seems to be a relevant
factor.
Anyhow, I know this is a very slippery bug and it may
be months before it is tracked down either here or elsewhere, but
I thought it would be helpful to at least document it for the
linux-kernel archiv
1GHz
CPU. So, more instructions per time slice seems to be a relevant
factor.
Anyhow, I know this is a very slippery bug and it may
be months before it is tracked down either here or elsewhere, but
I thought it would be helpful to at least document it for the
linux-kernel archiv
ing arch/i386/kernel/acpi.c should just go away, yes?
>
> Its purpose is probably better served by an ifdef, like you mentioned.
[...]
> > From: Adam J. Richter [mailto:[EMAIL PROTECTED]]
> >
> > Although the stock linux-2.4.0-test13pre3 does not allow
> > one
arch/i386/kernel/acpi.c should just go away, yes?
Its purpose is probably better served by an ifdef, like you mentioned.
[...]
From: Adam J. Richter [mailto:[EMAIL PROTECTED]]
Although the stock linux-2.4.0-test13pre3 does not allow
one to build the acpi interpreter as a loadable mod
will probably be the case
with most Linux distributions initially installed on ia64 hardware).
If need be, I would be willing to at least write a quick and
dirty #ifdef-based version of this proposed change.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL
will probably be the case
with most Linux distributions initially installed on ia64 hardware).
If need be, I would be willing to at least write a quick and
dirty #ifdef-based version of this proposed change.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL
In linux-2.4.0-test13pre3 (or maybe pre1 or pre2),
mm_struct->segments became mm_struct->context.segmnets. This change
adjusts linux-2.4.0-test13pre3/arch/i386/math-emu/fpu_system.h accordingly
so that i386 math emulation will compile again.
--
Adam J. R
In linux-2.4.0-test13pre3 (or maybe pre1 or pre2),
mm_struct-segments became mm_struct-context.segmnets. This change
adjusts linux-2.4.0-test13pre3/arch/i386/math-emu/fpu_system.h accordingly
so that i386 math emulation will compile again.
--
Adam J. Richter
.
The following patch brackets the (unused) offending declarations
in #ifdef __KERNEL__...#endif.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i
to compile.
The following patch brackets the (unused) offending declarations
in #ifdef __KERNEL__...#endif.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630
Apparently, in linux 2.4.0-test12-pre5,
address_space_operations->writepage went from having two parameters
to just one. fs/udf/inode.c apparently was overlooked in the patch.
Here is the one line change.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Su
o change things back.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free So
f PCI IRQ
initialization below. The only change was to delete the first
"if" statement. The rest of the diff lines are just the resulting
intentation and bracketing change.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
I IRQ
initialization below. The only change was to delete the first
"if" statement. The rest of the diff lines are just the resulting
intentation and bracketing change.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /
o change things back.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free So
Apparently, in linux 2.4.0-test12-pre5,
address_space_operations-writepage went from having two parameters
to just one. fs/udf/inode.c apparently was overlooked in the patch.
Here is the one line change.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
o build from your .config file.
Memo to Transmeta management: buy Linus a PictureBook. :-)
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United St
o build from your .config file.
Memo to Transmeta management: buy Linus a PictureBook. :-)
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United St
space optimizations
by modifying objdump. However, I do think that such an improvement
to gcc would be at least a bit useful to the larger user base than
just those people who use binutils-based systems.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \
Keith Owens <[EMAIL PROTECTED]> wrote:
>"Adam J. Richter" <[EMAIL PROTECTED]> wrote:
>> In reading include/linux/init.h, I was surprised to discover
>>that __init{,data} expands to nothing when compiling a module.
>>I was wondering if anyone is cont
.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest
Is there some reason why gcc does not put static data that
is explicitly initialized to zero in .bss? If not, then fixing
gcc would provide more space savings than these patches, and
improve more software than just the Linux kernel.
Adam J. Richter __ __ 4880
Is there some reason why gcc does not put static data that
is explicitly initialized to zero in .bss? If not, then fixing
gcc would provide more space savings than these patches, and
improve more software than just the Linux kernel.
Adam J. Richter __ __ 4880
.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest
Keith Owens [EMAIL PROTECTED] wrote:
"Adam J. Richter" [EMAIL PROTECTED] wrote:
In reading include/linux/init.h, I was surprised to discover
that __init{,data} expands to nothing when compiling a module.
I was wondering if anyone is contemplating adding support for
__init{,data}
the larger user base than
just those people who use binutils-based systems.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
release). The patch is FTPable from:
ftp://ftp.yggdrasil.com/pub/dist/device_control/kernel/pci_id_tables-2.4.0-test11-ac4.patch4.gz
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1
Fritzler's port.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest
ski that explains my reasons for sticking with
#ifndef MODULE...#endif rather than creating a new kernel facility
for something that, by the way, should become completely unused in
the next couple of months after 2.4.0 is released and the device
drivers are converted to the new PCI and isapnp interface
completely unused in
the next couple of months after 2.4.0 is released and the device
drivers are converted to the new PCI and isapnp interfaces:
|From: "Adam J. Richter" [EMAIL PROTECTED]
|To: [EMAIL PROTECTED]
|
|Thanks for the patch, but I think I'll stick with the ifdefs
|for no
Fritzler's port.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest
release). The patch is FTPable from:
ftp://ftp.yggdrasil.com/pub/dist/device_control/kernel/pci_id_tables-2.4.0-test11-ac4.patch4.gz
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1
Keith Owens <[EMAIL PROTECTED]> wrote:
>"Adam J. Richter" <[EMAIL PROTECTED]> wrote:
>> Note that this is not a "final" version. I plan to go
>>through all of the changes and bracket all of these new tables
>>with #ifdef MODULE...#endif
r code.
Any comments are welcome.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "F
;fs-".
Of course these changes will add string length checking.
Comments? Are the "fs-" and "if-" prefixes OK? (There
are currently no real modules that have names beginning with those
strings.)
Adam J. Richter __ __ 4880 Stevens Creek
zers (by the way, I did not invent that
practice for pci_device_id tables; I think it originated in usb/usb-ohci.c
by David Brownell). Again, the complete patch covering all of the
MODULE_DEVICE_TABLE changes is FTPable from
ftp://ftp.yggdrasil.com/pub/dist/device_control/kernel/pci_id_t
o/imsttfb.c Thu Nov 23 20:27:38 2000
@@ -47,6 +47,47 @@
#include video/fbcon-cfb24.h
#include video/fbcon-cfb32.h
+static struct pci_device_id imsttfb_pci_tbl[] __initdata = {
+ /* Apparently, this driver really does want to look at every PCI
+ display device made by
;fs-".
Of course these changes will add string length checking.
Comments? Are the "fs-" and "if-" prefixes OK? (There
are currently no real modules that have names beginning with those
strings.)
Adam J. Richter __ __ 4880 Stevens Creek
r code.
Any comments are welcome.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631
Keith Owens [EMAIL PROTECTED] wrote:
"Adam J. Richter" [EMAIL PROTECTED] wrote:
Note that this is not a "final" version. I plan to go
through all of the changes and bracket all of these new tables
with #ifdef MODULE...#endif so they do not result in complaints
about the
use of the vendor_id / device_id
pairs, and, if you want, ports the driver to the new hotplug PCI
interface, which might be useful, considering that I see ieee1394
CardBus cards everywhere.
Any feedback would be appreciated. Thanks in advance.
Adam J. Richter __ __ 4880 Stev
if
there are other device ID's besides 0x9128 and 0x9135 that
imsttfb.c is interested in, or is it OK to write the
pci_device_id table to just specify those two rather than all
PCI video cards made by IMS?
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED
>Keith Owens wrote:
>>
>> [Adam J. Richter]
>> > +static struct pci_device_id atp870u_pci_tbl[] __initdata = {
>> > +{vendor: 0x1191, device: 0x8002, subvendor: PCI_ANY_ID, subdevice: PCI_ANY_ID},
>> > +{vendor: 0x1191, device: 0x8010, su
Keith Owens wrote:
[Adam J. Richter]
+static struct pci_device_id atp870u_pci_tbl[] __initdata = {
+{vendor: 0x1191, device: 0x8002, subvendor: PCI_ANY_ID, subdevice: PCI_ANY_ID},
+{vendor: 0x1191, device: 0x8010, subvendor: PCI_ANY_ID, subdevice: PCI_ANY_ID},
It would make it easier
if
there are other device ID's besides 0x9128 and 0x9135 that
imsttfb.c is interested in, or is it OK to write the
pci_device_id table to just specify those two rather than all
PCI video cards made by IMS?
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED
of the vendor_id / device_id
pairs, and, if you want, ports the driver to the new hotplug PCI
interface, which might be useful, considering that I see ieee1394
CardBus cards everywhere.
Any feedback would be appreciated. Thanks in advance.
Adam J. Richter __ __ 4880 Stevens
eo 4
drivers/mtd 1
drivers/net/tokenring 1
drivers/pcmcia 1
drivers/sbus/char 1
drivers/telephony 1
drivers/video 7
As you can see, we are converging on complete MODULE_DEVICE_TABLE
coverage for all PCI drivers.
--
Adam J. Richter __ _
>"Adam J. Richter" wrote:
>> Just to avoid duplication of effort, I am posting this preliminary
>> patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
>> drivers in linux-2.4.0-test11/drivers/block. In response to input from
>>
to three entries, although I think that may be going to far, as I would
really like to keep the number of files that initialize the pci_device_id
arrays this way low so that changing struct pci_device_id remains feasible.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
an empty value in the case of class_mask. depmod deliberately
includes a format comment at the start of modules.pcimap so that the
structure can be changed in the future.
However, thanks for your feedback. I will take it into
consideration.
Adam J. Richter __ __ 4880 Ste
initializers is still kept relatively
small, so a change to pci_device_id that would require changing the
initializers would involve changing only a relatively small number
of drivers, as opposed to potentially all ~150 PCI drivers.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd
initializers is still kept relatively
small, so a change to pci_device_id that would require changing the
initializers would involve changing only a relatively small number
of drivers, as opposed to potentially all ~150 PCI drivers.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd
of class_mask. depmod deliberately
includes a format comment at the start of modules.pcimap so that the
structure can be changed in the future.
However, thanks for your feedback. I will take it into
consideration.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite
to three entries, although I think that may be going to far, as I would
really like to keep the number of files that initialize the pci_device_id
arrays this way low so that changing struct pci_device_id remains feasible.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
"Adam J. Richter" wrote:
Just to avoid duplication of effort, I am posting this preliminary
patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
drivers in linux-2.4.0-test11/drivers/block. In response to input from
Christoph Hellwig, I have reduced my
eo 4
drivers/mtd 1
drivers/net/tokenring 1
drivers/pcmcia 1
drivers/sbus/char 1
drivers/telephony 1
drivers/video 7
As you can see, we are converging on complete MODULE_DEVICE_TABLE
coverage for all PCI drivers.
--
Adam J. Richter __ _
101 - 200 of 256 matches
Mail list logo
