The Place to Start for Operating System Developers
https://f.osdev.org/
Well, if there were a driver for something like a floppy drive or anything already made, then that alone would make it worth implementing(since it looks easy to implement anyway) but I'm afraid I will gain nothing by having it in my kernel.JackScott wrote:It's doesn't have a reference implementation because nobody has implemented one yet.
And it appears dead because nobody has implemented it yet.
I find that ridiculous.. there are many kernel module driver blobs out there.. why don't they keep linux from supporting kernel modules too then?Love4Boobies wrote:Don't forget about the UDI (Uniform Driver Interface). It's probably the most complex and is probably more common; although unfortunately, there is really no such thing as a common driver interface. You can really gain any benefit from implementing any of these in your kernel.
UDI is not really accepted (by GNU esp.) due to philosophical concerns - people are allowed to make non-open-source UDI drivers and that's not good for open-source-ness apparently. That's why they didn't want UDI in Linux.
I thought UDI was dead... Anyway, the GNU folks really have nothing at all to do with the linux kernel. They may not have wanted UDI in the kernel, but that's not the reason it isn't in the kernel. The real reason UDI isn't in the linux kernel is because the linux kernel devs don't believe in having a stable driver API. They find it too limiting. Just look at linux-2.6.29/Documentation/stable-api-nonsense.txt for more information on that.Love4Boobies wrote:Don't forget about the UDI (Uniform Driver Interface). It's probably the most complex and is probably more common; although unfortunately, there is really no such thing as a common driver interface. You can really gain any benefit from implementing any of these in your kernel.
UDI is not really accepted (by GNU esp.) due to philosophical concerns - people are allowed to make non-open-source UDI drivers and that's not good for open-source-ness apparently. That's why they didn't want UDI in Linux.
I didn't mean they didquok wrote:Anyway, the GNU folks really have nothing at all to do with the linux kernel.
I wasn't aware of that. I just remembered reading what I said on the wiki. I'll be sure to check that file.They may not have wanted UDI in the kernel, but that's not the reason it isn't in the kernel. The real reason UDI isn't in the linux kernel is because the linux kernel devs don't believe in having a stable driver API. They find it too limiting. Just look at linux-2.6.29/Documentation/stable-api-nonsense.txt for more information on that.
Code: Select all
int setmode(int vmode)
{
vgasupport(VGA_SETMODE,vmode);
}
int getmode(void)
{
vgasupport(VGA_GETMODE,&vmode);
return vmode;
or
return vgasupport(VGA_GETMODE);
}
Code: Select all
int vgasupport(int ser, ...)
{
switch(ser){
case VGA_SETMODE:
vga_setmode(argv[0]);
break;
case VGA_GETMODE:
return vga_getmode();
break;
}
}
int vga_setmode(int vmode)
{
drvlib(BIOSINT,0x10,vmode); // not shown but this is a function in the driver.c file
or
// code to set registers
}
This still doesn't apply to the syscall approach because an asm programmer can make a syscall without type checking and this is a driver written for kernel level, hopefully by a capable driver coder. The kernel driver coder would have type checking thru the device header file. Also i planned for the device driver to be compiled already so its distributed as either a binary or source code. This way a user downloads the binary and the single wrapper driver (kernel specific) loads whichever manufactures device driver was needed.AntoineKaufmann wrote:I don't think that this is necessarily a good Idea. With this approach you'll have to do much more work to check data types and parameter count. If you use a wide interface, the compiler does this work for you provided that you use a static typed language.
The BIOS was only 1 example of this, and maybe it wasnt done right with vender extensions but it works and can be extended for purposes not thought of. The VGA card makers will add a million of them that as an OS coder i didnt know existed or that was needed for venom OS to look flash ;)AntoineKaufmann wrote: Of course it is simpler to change your type of interface, but you cannot avoid incompatibilities with that approach, you just hide them. You could do some checking of a version number or something like that, but what do gain then compared to the wide interface?
The BIOS doesn't seem to be a good example to me. If you look at all the incompatible vendor extensions e.g. to get the memory map...
You can't change the specification or remove a function anyway if you're not going to break compatibility. You only achieve that the compiler/linker can't shout at you if you try to do so. This is not an improvement.b.zaar wrote:the ioctl interface can be extended easier with more functions or removing functions as each function doesnt need to be linked.