OSDev.org

POSIX pthreads aren't too bad, but they aren't as elegant/simple as possible. This is because they're designed to work on a variety of OSs, and therefore need to at least cope with different ways of handling scheduling, processes, threads, etc. For example, for Linux everything is a process (a thread is just a process that shares an address space with another process), while for some versions of *NIX threads are implemented in a user-level library and the kernel has nothing to do with them. The POSIX stuff also has a lot of things I think you can ignore (like thread specific data, signals, etc).

I'm thinking that some form of "OS specific" wrapper is going to be unavoidable, and that EDI drivers could just export standard functions that are either linked directly to the kernel (for monolithic kernels) or linked to a generic wrapper or shared library/DLL (for micro-kernels). That way the EDI driver source code itself doesn't need to care whether "port_read_method()" is actually routed through twelve different processes before being done or if it's an inline function, and the kernel or the wrapper could use EDI driver functions like "readSectors(LBA_address, count, void *destination)" or "draw3Dtriangle(point1, point2, point3, texture, opacity)".

Crazed123 wrote:

For my OS device drivers are normal processes, which means the same 32 bit processes/driver binary could be run on a 64 bit version of the OS. In this case CR3 would be a 64 bit register (the driver would expect a 32 bit register) and the flags used for paging (PAE, PSE) features in CR0 and CR4 might be misleading.

Hence the "intreg" type. On a 64-bit system it would be compiled as an int64_t rather than an int. Is there a preprocessor symbol I can check the definition for to make the declaration clearer?

Crazed123 wrote:

I don't know much about other architectures, but the PCI standard (and PCI devices) are cross-platform. It shouldn't be too hard to make portable PCI devices. Some hardware is tricky though (legacy ISA stuff). I'm not sure how other architectures handle I/O port ranges though (e.g. the chipset could memory mapped them into a special memory area or something).

You could try to make EDI work with "similar enough" architectures (without worrying about the radically different architectures)...

Let's put it this way: I have no intention to accomodate IA32-only features such as segmentation, but processor-portability takes lesser priority than creating something people will want to code for on IA-32. Remember how Linux started life for the IA-32 only?

Crazed123 wrote:So we've basically got: cacheable memory, "writes-cause-flush" caching, totally uncacheable, and "write-combining" caching. Or is "write-through" a separate type from "writes-cause-flush"?

Crazed123 wrote:Unfortunately, what you said about your device manager really only helps with your kernel. Not that your kernel is insignificant or so bad or anything (DON'T take this personally), but what's really needed is some simple mechanism for the driver to identify the hardware it drives, and be given its hardware parameters.

EDI_start(EDI_resourceList *resourceList) {
    int status;

    if( resourceList == NULL ) {
        status = doProbing();
        if( status == OK ) {
            status = tell_the_OS_which_resources();
        }
    } else {
        status = scan_resources(resourceList);
        if( status == OK ) {
           status = check_if_device_is_good();
        }
    }
    return status;
}

Crazed123 wrote:I'm not sure about what it would be, but I think that some kind of data structure should be used to convey what hardware a driver drives. A set (or array, or whatever) of these could be declared const in the driver with a fixed name. When the driver is loaded (I think it's safe to assume drivers will be loaded in some object format that supports symbols, no?) the kernel can read this symbol, read the data structures there, and use this information to know about the drivers hardware.

Crazed123 wrote:I'm thinking like you, that the EDI layer the driver sees may end up being a library rather than the kernel itself. A monolithic kernel with the ability to call functions in the driver directly wouldn't need it, but a microkernel could link an EDI-marshalling layer to the driver. This layer would marshall driver calls to EDI into proper messages, unmarshall kernel/outside-world calls on the driver into proper function calls, run silently (so the driver doesn't know it isn't talking to a function-calling kernel), and be written uniquely for each OS.

BTW even though you've already got an example video/console driver, I'd avoid video (too complicated for the first device type). I was thinking of keyboard, mouse, joystick or serial port...

paulbarker wrote: Whenever I'm looking at example drivers, I think the best one to write would be a Bochs debugging port driver. You simply write one char at a time to port 0xe9, with no reading allowed.

For me, this information comes from PCI configuration space (or some other form of auto-detection). The device driver would check that it was given access to everything it needs and abort with an error if it wasn't.

It can't be determined when the driver is compiled - in a 32 bit platform "intreg" would be 32 bit, so when a 32 bit binary is running under a 64 bit version of the OS some things don't fit anymore. Even if "intreg" is always 64 bit the driver won't know when the upper 32 bits are used. You could probably solve this by providing a way for the device driver to find out what mode the kernel is operating in at run time, but that seems too messy (given that I can't think of a situation where the driver would actually need to know the contents of any of the registers).

Of course now that I've said this, there is one area. For DMA, how does the device driver find the physical addresses, how does it know if they are 32 bit or 64 bit, and (for some OSs) what does it do if the addresses are 64 bit but the device itself isn't capable of transferring data to/from pages above 4 GB (or above 16 MB)?

For my OS, I don't allow anyone to get the physical addresses for general pages. Instead, device drivers must allocate memory using special "allocate page/s for DMA" kernel functions, which are the only way to get any physical addresses to use for DMA or bus mastering. This means that a device driver must use "bounce buffers" and can't transfer data directly into another process's address space (which is better for performance and something that most other OSs would do).

Sure, but you're doing design work, rather than implementing a design. For Linux they mostly just copied the portable design of UNIX, which would've made it much easier to port Linux to other architectures and would've avoided the need to completely redesign non-portable things when it's too late...

paulbarker wrote:

BTW even though you've already got an example video/console driver, I'd avoid video (too complicated for the first device type). I was thinking of keyboard, mouse, joystick or serial port...

Whenever I'm looking at example drivers, I think the best one to write would be a Bochs debugging port driver. You simply write one char at a time to port 0xe9, with no reading allowed.

Crazed123 wrote:

For me, this information comes from PCI configuration space (or some other form of auto-detection). The device driver would check that it was given access to everything it needs and abort with an error if it wasn't.

Only teensy issue is drivers like the keyboard, mouse, serial port, etc. that don't get auto-detected. Though I'm sure they can probe, right?

Crazed123 wrote:

For my OS, I don't allow anyone to get the physical addresses for general pages. Instead, device drivers must allocate memory using special "allocate page/s for DMA" kernel functions, which are the only way to get any physical addresses to use for DMA or bus mastering. This means that a device driver must use "bounce buffers" and can't transfer data directly into another process's address space (which is better for performance and something that most other OSs would do).

I do believe I designed EDI-STREAM-DMA for this very purpose. A driver writes to its DMA stream, and the EDI-layer sends the data to the DMA hardware *safely*.