standing by..

[hopity hop]

why is it so damn difficult ?

http://www.intel.com/technology/iapc/acpi/faq.htm#linux

[Pype.Clicker]

lol...
because of software & hardware variety combined with the fact the problem 'per se' is *not* simple ...

In addition, for most power control was simply a "gadget" on desktop system, while it has become mandatory for laptop systems ...

[maria]

why every single os i know needs drivers in order to access a device ?
can the device not handle itself ?
have its own embedded microprocessor, rom, upgradeable bios ?
represent a node of a machine's internal network ?
acpi or not, i haven't seen happening yet
drivers are os specific,
and a burden to write or find
as a result, i am unable to try every new os
instead, i am forced to buy hardware already supported by a specific os

[Brendan]

Hi,

why every single os i know needs drivers in order to access a device ?
can the device not handle itself ?
have its own embedded microprocessor, rom, upgradeable bios ?
represent a node of a machine's internal network ?
acpi or not, i haven't seen happening yet
drivers are os specific,
and a burden to write or find

Some devices (SCSI, video) have a ROM that allows the CPU to do certain things if the CPU is in real mode. Real mode is no longer used but the ROMs still use real mode for compatibility reasons. If the device had it's own embedded microprocessor then the OS would still need a device driver so it knows how to talk to the device's embedded microprocessor. The 80x86 architecture has a 256 Kb area reserved for device ROMs, which is far too small for all devices (this area is used by the first video card's ROM, some other device's ROMs (SCSI) and the system BIOS).

Device drivers are a software interface to the device/s that allow the OS to access similar devices (via. the device drivers) in the same way - for e.g. the OS uses a common interface to talk to the device drivers for CD-ROM, IDE, SCSI, floppy, etc even though the devices themselves use radically different hardware interfaces. The OS's common interface/s depend heavily on the design of the OS, and are different for each different OS.

There is a project called the "Uniform Driver Interface" at http://www.projectudi.org/ which is attempting to create a way for OSs to support standard/portable device drivers, in order to minimize this problem and to reduce the cost of writing device drivers for hardware manufacturers. While this is a noble goal I fail to see how it can be done (given the diversity of OS's and architectures) without severly limiting features and/or performance. For example an UDI driver needs to work in tiny (embedded) systems and large scale clustered/distributed systems, and work in kernel mode, user mode or split (with part of the driver in kernel mode and the rest in user mode). In addition UDI would restrict the hardware manufacturers ability to introduce new features and devices. For instance, if someone wanted to create a sound card with a built in radio tuner they'll have a hard time writing a UDI driver for it.

as a result, i am unable to try every new os
instead, i am forced to buy hardware already supported by a specific os

There are some devices that are standard, or support a standard/legacy hardware interface (PS/2 keyboards, mice, floppy disks, timer chips, serial ports, modems, parrallel ports, printers, ATAPI CD-ROM, IDE hard drives & controllers) that should be usable with generic device drivers. For video the OS can set a default video mode while in real mode (during boot) so that video can be used without a device driver (with restrictions - no hardware acceleration, no video mode switches). Using just these devices you should be able to test and use any OS. Non-generic device drivers are still required to use the full performance and features of each device though.


Cheers,

Brendan

[Pype.Clicker]

why every single os i know needs drivers in order to access a device ?
can the device not handle itself ?

So spoke the CodePoet ...

Basically, a driver contains some glueing code between the hardware programming and the OS internals. If you get a look at this essay of mine, you may get a clue of why it's not always easy.
In a modern OS, the driver needs to perform inter-process signals to wake up waiting threads, register interrupts handlers, request/map/unmap/free memory, set up timers, and so on.
All these things are handled in a sensible different manner ...

UDI achieves uniformisation by providing an abstract environment that OS and drivers use to communicate with each other. A driver that is UDI-compliant will not notice in which system it runs provided that the system has an UDI framework.

This way, the NxM problem is reduced to N+M ... which is sensibly smaller

[kataklinger]

why every single os i know needs drivers in order to access a device ?
can the device not handle itself ?
have its own embedded microprocessor, rom, upgradeable bios ?
represent a node of a machine's internal network ?
acpi or not, i haven't seen happening yet
drivers are os specific,
and a burden to write or find
as a result, i am unable to try every new os
instead, i am forced to buy hardware already supported by a specific os

Sorry, but I must ask: "What are you doing here?" ???

[xdfth]

-- suppressed content #001 -- read this thread to find out why --

[Pype.Clicker]

-- suppressed content #001 -- read this thread to find out why --

completely OT:
@codepoet, for your mySqL as non-root, contact me (ICQ, mail, private message, whatever): i may have a link for you ...

[kataklinger]

Yes, you are right Pype!