turdus wrote:
Owen wrote:
And how do you handle relocation? ...
UDRV does not handle it in any way. It's the duty of your kernel. UDRV simply marks entry points within image.
So I CAN'T use a PE driver on an ELF kernel. As I suspected!
turdus wrote:
Owen wrote:
The __TEXT segment of these binaries starts somewhere around 8GB past the load address...
In this case you map the image at 8GB, so you should add 8G to every entry point to get effective address. Tadaa! Would be the same procedure if mapping address was 0x1234000, wasn't it? Within text use PIC-relative addresses if possible (requires additional relocation information for protected mode. But UDRV is not for the past, it's for the future, and thankfully none needed for long mode).
The load address of these binaries is 8GB before the __TEXT segment, because there is another (8GB!) segment before the text segment.
turdus wrote:
Owen wrote:
CDI has a central registry. Go contribute it to there...
Now that's what I call reinventing the wheel. To my opinion there's no need for yet another registry (by the way, PCI ID covers much more and totally open. Not to mention it's editable like a wiki.)
Find me the PCI ID for a keyboard
turdus wrote:
Owen wrote:
The file system protocol seems to be synchronous. No defined threading model - and if your threading model involves shared memory concurrency, its' a hard threading model which will result in many bugs.
Threading model is just like the mapping address, out of the scope. It has nothing to do with the driver model. If you want to execute the same driver in separated threads, then it's your kernel's duty let that happen without interference. If the driver is supposed to use shared memory, it must be able to use that for locks or semaphores as well. If memory is shared among threads of the same driver, there's no problem; however drivers need to speak the same language on locking, but that's totally out of the scope of UDRV.
So, what? A driver is supposed to support being invoked on a single device from multiple threads or a single thread or whatever the kernel wants?
OK, great, every driver is going to be horrifically buggy from threading issues that were untested on its' origin platform.
turdus wrote:
Owen wrote:
But mainly, it seems to be synchronous, which is just a terrible idea.
I think you have been misguided by names. It's totally valid to issue a command to a driver, which returns instantly with a sequence number, and later on, when the job is done, informs your kernel via sendsignal(sequence). Originally it was called notifykernel, but sendsignal seemed more like POSIX. The supported mode can be queried via getcapability(). If both sync and async supported, kernel can switch by applying a cmd(this,"sync",true/false) call.
(Hint: as mentioned before on this forum long ago, my kernel supports 4 system calls, 2 for synchronous and 2 for asynchronous messaging. If anyone, I would not build on synchronous only
)
And how does it pass information back to the kernel?
How does it request notification of events?
Why are we passing back sequence numbers, rather than some form of pointer or handle?
Why are we considering "POSIX signals design", when they're widely considered to be one of the worst aspects of POSIX (from the perspective of doing complex things)?
How do I allocate a sequence number? What happens if sequence number allocation fails? What happens if memory allocation fails?
turdus wrote:
Owen wrote:
What relevance has age?
Much. 4 years enough to write a lot of drivers, on the other hand you won't get far with them in 0 sec.
I see no relevance. UDRV isn't going to magically attain drivers by being young.
turdus wrote:
Owen wrote:
So VMS was a bad example.
Why? I think it's just as good as any other would. You see every command language mimic the structure of human sentence. There's a verb about what to do, and other words narrowing on how to do it and with what. Quite common.
Owen wrote:
How about Mac OS Classic?
Beside of the obvious fact that no new specification will ever be implemented on a proprietary end of life OS, this is from the wiki:
Quote:
If you do some extreme stuff without shell, you'll need to provide a way to communicate with the UDRV compatible devices (voice command, GUI whatever).
If it's not clear, you have to provide exactly the same commands (reset, get, set, list, path optionally update). It does not matter if "reset" (or any translated version) is spoken, typed or clicked on, the specification expects the same to happen from the device's point of view.
OK, so its' a "maybe available" command line interface.
Maybe slightly useful, but I don't see any great utility in that.
(BTW, Mac OS Classic was just an example of an OS without a command line. They may be rare, but they exist. Of course, one can hypothesize an OS where the "command line" is not built upon programs)