Commit graph

6 commits

Author SHA1 Message Date
David van Moolenbroek
b4d909d415 Split block/character protocols and libdriver
This patch separates the character and block driver communication
protocols. The old character protocol remains the same, but a new
block protocol is introduced. The libdriver library is replaced by
two new libraries: libchardriver and libblockdriver. Their exposed
API, and drivers that use them, have been updated accordingly.
Together, libbdev and libblockdriver now completely abstract away
the message format used by the block protocol. As the memory driver
is both a character and a block device driver, it now implements its
own message loop.

The most important semantic change made to the block protocol is that
it is no longer possible to return both partial results and an error
for a single transfer. This simplifies the interaction between the
caller and the driver, as the I/O vector no longer needs to be copied
back. Also, drivers are now no longer supposed to decide based on the
layout of the I/O vector when a transfer should be cut short. Put
simply, transfers are now supposed to either succeed completely, or
result in an error.

After this patch, the state of the various pieces is as follows:
- block protocol: stable
- libbdev API: stable for synchronous communication
- libblockdriver API: needs slight revision (the drvlib/partition API
  in particular; the threading API will also change shortly)
- character protocol: needs cleanup
- libchardriver API: needs cleanup accordingly
- driver restarts: largely unsupported until endpoint changes are
  reintroduced

As a side effect, this patch eliminates several bugs, hacks, and gcc
-Wall and -W warnings all over the place. It probably introduces a
few new ones, too.

Update warning: this patch changes the protocol between MFS and disk
drivers, so in order to use old/new images, the MFS from the ramdisk
must be used to mount all file systems.
2011-11-23 14:06:37 +01:00
Ben Gras
b1eba81b9d simplify build logic a bit
. always compile acpi, with clang, so never have
	  build/clean inconsistencies; can be enabled (i.e. run
	  at boot time) by setting acpi variable in the boot monitor
	. always strip binaries with the right strip cmd, so never
	  have ack/elf strip inconsistencies
2011-11-18 17:11:17 +01:00
Arun Thomas
b956c8735e Fix GCC image building 2011-07-09 15:04:42 +02:00
Tomas Hruby
40bfed28cd ACPI pci-to-pci bridges
- every pci device which implements _PRT acpi method is considered to
  be a pci-to-pci bridge

- acpi driver constructs a hierarchy of pci-to-pci bridges

- when pci driver identifies a pci-to-pci bridge it tells acpi driver
  what is the primary and the secondary bus for this device

- when pci requests IRQ routing information from acpi, it passes the
  bus number too to be able to identify the device accurately
2010-10-21 17:07:09 +00:00
Tomas Hruby
613ff40936 acpi driver Makefile fix
- by Antoine Leca
2010-10-15 22:20:01 +00:00
Tomas Hruby
9560b6dea8 ACPI driver
- 99% of the code is Intel's ACPICA. The license is compliant with BSD
  and GNU and virtually all systems that use ACPI use this code, For
  instance it is part of the Linux kernel.

- The only minix specific files are

  acpi.c
  osminixxf.c
  platform/acminix.h

  and

  include/minix/acpi.h

- At the moment the driver does not register interrupt hooks which I
  believe is mainly for handling PnP, events like "battery level is
  low" and power management. Should not be difficult to add it if need
  be.

- The interface to the outside world is virtually non-existent except
  a trivial message based service for PCI driver to query which device
  is connected to what IRQ line. This will evolve as more components
  start using this driver. VM, Scheduler and IOMMU are the possible
  users right now.

- because of dependency on a native 64bit (long long, part of c99) it
  is compiled only with a gnu-like compilers which in case of Minix
  includes gcc llvm-gcc and clang
2010-09-02 15:44:04 +00:00