OSDev.org

You're right, the osdep structs are a good point why it's not even possible for a single version. Too bad, I can keep pulling a Linus on API stability.

You simply don't understand.
The whole point is: let's say you have a kernel in ELF, that knows nothing about PE format. With UDRV you'll still able to load and use a driver in that non-native format, by searching for UDRV block and get the info from there. No sources, no compilation. You would be also able to configure the devices driven by that driver in a standard way.

@Owen: "I regularly run binaries where there is a greater than 4GB difference between the load address of the lowest segment and the end of the binary"
And what? I don't think you split the text section. It's easier to keep it just as is, and allocate memory for data at whatever address you want. Nothing stops you from that, still 32 bit more than enough to mark entry points within text.

About CDI category: "So add a category?" Great, and my kernel will have a category that no other OS knows about. You really fail to see the benefit of a central registry such as PCI ID class?

"too simplistic for anything but the most basic of hobby kernels"
Give it a think again. It was it's goal to be simplistic, and to help hobby kernel developers. And I disagree on it's only useful for basics.

About no UDI drivers and no UDRV drivers: the difference is that UDRV is a draft, while UDI is over 4 years old. Despite of that, you compare them?!?

"The commonality between, say, the UNIX and VMS command line interfaces is very slim." Don't tell me, I used to be a VMS system admin for years, and UNIX twice the time. And you're wrong, they have a lot of common. In fact, there's only minor difference in syntax, not semantics.

"Why am I configuring the driver? That tells me something has gone wrong somewhere."
I agree, you failed to read or understand. I was talking about the devices.

"(And why am I not using a GUI, anyway?)"
Again, failed to read.

"Which is fine, but I don't see why you couldn't add that feature to CDI."
Because it cannot be done without modifying it so much, that it wouldn't be CDI any more.

turdus wrote:You simply don't understand.
The whole point is: let's say you have a kernel in ELF, that knows nothing about PE format. With UDRV you'll still able to load and use a driver in that non-native format, by searching for UDRV block and get the info from there. No sources, no compilation. You would be also able to configure the devices driven by that driver in a standard way.

And how do you handle relocation? ...

turdus wrote:@Owen: "I regularly run binaries where there is a greater than 4GB difference between the load address of the lowest segment and the end of the binary"
And what? I don't think you split the text section. It's easier to keep it just as is, and allocate memory for data at whatever address you want. Nothing stops you from that, still 32 bit more than enough to mark entry points within text.

The __TEXT segment of these binaries starts somewhere around 8GB past the load address...

turdus wrote:About CDI category: "So add a category?" Great, and my kernel will have a category that no other OS knows about. You really fail to see the benefit of a central registry such as PCI ID class?

CDI has a central registry. Go contribute it to there...

turdus wrote:"too simplistic for anything but the most basic of hobby kernels"
Give it a think again. It was it's goal to be simplistic, and to help hobby kernel developers. And I disagree on it's only useful for basics.

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.

But mainly, it seems to be synchronous, which is just a terrible idea.

turdus wrote:About no UDI drivers and no UDRV drivers: the difference is that UDRV is a draft, while UDI is over 4 years old. Despite of that, you compare them?!?

What relevance has age?

turdus wrote:"The commonality between, say, the UNIX and VMS command line interfaces is very slim." Don't tell me, I used to be a VMS system admin for years, and UNIX twice the time. And you're wrong, they have a lot of common. In fact, there's only minor difference in syntax, not semantics.

So VMS was a bad example.

How about Mac OS Classic?

turdus wrote:About CDI category: "So add a category?" Great, and my kernel will have a category that no other OS knows about. You really fail to see the benefit of a central registry such as PCI ID class?

The central registry is cdi.git.

It's actually a good comparison. PCI IDs weren't assigned on the day that the first PCI standard was published, but they are added whenever someone needs one for a new device. In the same way, categories are added to CDI whenever someone needs one for a new driver (and hopefully contributes not only the category name, but the whole driver to cdi.git - that's the whole point of a common interface, after all).

Kevin wrote:You're right, the osdep structs are a good point why it's not even possible for a single version. Too bad, I can keep pulling a Linus on API stability.

I recently bought a wifi adaptor for my rpi and found that I need to rebuild the driver every time I perform kernel upgrade, even just one reversion ahead without anything matter to the driver.
This is just insane. What happened to the driver interface?

IMO a good driver interface should provide certain degree of backward compatibility, and even better with a bit of forward compatibility (the other hand, the kernel backward compatible the driver).

Torvalds happened.

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.

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).

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.)

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.

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 )

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.

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:

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.

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:

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)

Owen wrote:So I CAN'T use a PE driver on an ELF kernel. As I suspected!

You can.

Owen wrote:The load address of these binaries is 8GB before the __TEXT segment, because there is another (8GB!) segment before the text segment.

Who cares? Add the offset where you have the binary mapped and you're good to go. Referencing data segment before the text segment with PIC is rather easy.

Owen wrote:Find me the PCI ID for a keyboard

Class: 0x09 Input device controller
SubClass: 0x00 Keyboard
Happy? We are talking about PCI ID Device Classes here.

Owen wrote: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?

No. The driver is supposed to execute in multiple threads, that's all. There are drivers that typically runs as single thread, like PS2 keyboard driver. You won't have more of that on one board, on the other hand you may have several network cards of the same chipset.
It's up to the kernel how to use them. You see the whole situation is upwards-down. The kernel examines system descriptors (like DSDT for example or iterates on pci bus), and already know how many instance of a specific driver it will need. Probably one keyboard, but more ethernet. The kernel is only in a need to have a code that interacts with the devices. It's definitely not the UDRV's scope to cover this.

Owen wrote:OK, great, every driver is going to be horrifically buggy from threading issues that were untested on its' origin platform.

Look, any process that's not capable of proper lock handling would be horrifically buggy. Not UDRV specific in any way.

Owen wrote:And how does it pass information back to the kernel?

How does it request notification of events?

Read the spec. It's there.

Owen wrote:Why are we passing back sequence numbers, rather than some form of pointer or handle?

Because the spec says so. Why do POSIX have standard stream as 0,1,2?

Owen wrote: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)?

It has nothing to do with POSIX singals, I must remind you. It's a callback.

Owen wrote:How do I allocate a sequence number? What happens if sequence number allocation fails? What happens if memory allocation fails?

Something you would know if the spec would be ready. Now you'll never know.

Owen wrote:

turdus wrote: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.

Bad for you. You've compared a draft to a specification already in use.

Owen wrote:Maybe slightly useful, but I don't see any great utility in that.

Having a standard way to configure drivers? How come you don't see?

Owen wrote:(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)

Yes.

Being butthurt apparently doesn't improve your argumentation skills.

In total:
- Yes it is
- I don't care
- I didn't understand the argument
- I didn't understand the argument
- Opinion
- Retort
- Because I say so
- I didn't understand the argument
- I don't care
- I don't care
- I didn't understand the argument
- Admitting defeat.

I suggest we keep it at this because you're only going to draw irritation at this rate.

"Such discussion, much opinions."

Personally I like UDI 'cause it works. I have read specifications from A to Z and seen example drivers. Despite that I'm still amateur/hobbyist I feel like UDI is more useful if you are really going to write kernel with plans for operating system.

But ... BUT. There is CDI and UDRV. So why don't we just sit down and create (or reinvent) our own device interface. Write our own specification, write interface specification instead of useless discussions about which one is better, which is more useful and etc. I think more useful is to do something.

Because of http://xkcd.com/927/ ?

Suggesting everyone's own driver interface is the same as having no standard - which is fine, but trying to push each such interface to others is a bad idea and we'll probably get flooded with suggestions that are another order of magnitudes worse than this thread had to offer.