Re: puc(4) man page update?


On Jul 4, 2008, at 6:08 PM, John Baldwin wrote:

The
attachments get bound at runtime. This is actually an important
feature.

It's an important feature of KOBJ, yes. The point of compiling
drivers into the kernel is to get just what you need. Not a
bunch of bus attachments you don't want. Modules have pretty
much all bus attachments because they need to work with
whatever kernel they're loaded in.

So, sio(4) is not following the rules in the strictest sense.
That's why sio(4) is a bad example, why the problem is not
adequately acknowledged and people keep running into the same
old problems of things not working "as expected".

This is because acpi is a module. One way this could be fixed is to not put
ISA devices enumerated by ACPI on acpi0, but instead of an ACPI- aware ISA bus
driver for devices on ISA/LPC that ACPI enumerates.

Agreed. For this to work on ia64, we also have to clean up
the ISA related code and some drivers. We have to remove
the assumption of having (legacy) PC hardware from it. The
legacy PC code must be moved under a different option. Think
about syscons, PnP, ISA DMA and option ROM. Those options
could be put under an option LPC or something.

For example: we could have an option LPC that is what option
ISA is now, but excludes the isa(4) bus driver. The ISA option
would change to mean the isa(4) bus driver only.

In a way acpi(4) is that new isa(4) bus driver, but we didn't
change option ISA to exclude the current isa bus. In other
words, we didn't add support for hints to acpi(4).

The amount of work is to eliminate the isa bus. That gives
exactly what you suggest, modulo naming.

Also, none of that will
fix any of the actual problems people have (i.e. COM1 being sio1 and COM2
being sio0 because the BIOS lists them backwards. This happens to work in
the non-ACPI case with PNPBIOS due to far grosser hacks that cause PNPBIOS
devices to not even be used if hints are present.)

That's still a different issue and unrelated.

--
Marcel Moolenaar
xcllnt@xxxxxxx



_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • mse reorg
    ... I've reorganized the mse driver. ... I've split it up into cbus and isa ... bus front ends, and a core back end and moved it to dev/mse. ... both isa and cbus is flawed, ...
    (freebsd-hackers)
  • Re: PC104 Bus support
    ... PC/104 is generally not 'enumerated' in the same way PCI is; it's just ISA ... You'll need a driver of some sort for your A/D card, but, assuming it's not ... > If I have a PC104 bus on my CEPC, do I need a driver to support it? ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [ALSA STABLE 3/3] a few more -- unregister platform device again if probe was unsuccessf
    ... with nothing other than the driver available to probe ... bus", where the _user_ would first need to setup the hardware from userspace by echoing values into sysfs. ... With an ISA bus type, ...
    (Linux-Kernel)
  • Re: [PATCH/RFT 0/13] x86: unify vmlinux.lds
    ... Disabling lock debugging due to kernel taint ... # Bus options (PCI etc.) ... # Generic Driver Options ...
    (Linux-Kernel)
  • Re: [PATCH 0/13] Time: Generic Timeofday Subsystem (v B10)
    ... bus type 'platform' registered ... Registering sysdev class '' ... device class 'pci_bus': registering ... usbcore: registered new driver usbfs ...
    (Linux-Kernel)