There are some drivers ofcourse, which there is no point of sharing. Timers and interrupt controllers are too fundamental to abstract, because not only the rest of the kernel, but every other driver will depend on them. Most will want console output available before even interrupts have been initialized, so that's another thing that needs to be special cased for each kernel (though code is mostly trivial).
The Original Reason
This is the original reason I post the code which you may remember as being two files only in really small text so it would not bulk up the thread. Lets see how I understood a part of you're post.
There are some drivers ofcourse,
The topic is drivers, which you say there is no point of sharing. Ok. Lets get to the meat.
Timers and interrupt controllers are too fundamental to abstract, because not only the rest of the kernel, but every other driver will depend on them.
Alright. Here you go. They are too fundamental to abstract. Yet honestly you just abstracted them you're self. You took a driver/device and its complex workings, which I mean as one timer device which may not be initialized and controlled the same as another, and you abstracted it by considering it to do one thing such as provide
a time as a timer by ignoring the inner workings of how you make it provide this
time or
timer concept. You might write a certain sequence of bytes that could be completely different from device to device that is considered a programmable interrupt timer (which programmable interrupt timer is a abstraction).
You took the device (8253 or APIC) as a specific object or instance and pulled a characteristic from it. The APIC provides more than a timer therefore it is abstracted and looks just like the 8253 when abstracted considering it a programmable interrupt timer. The characteristic is the pulses for the timer when it triggers its self.
A meaning of the word abstract:
2. expressing a quality or characteristic apart from any specific object or instance, as justice, poverty, and speed.
One characteristic of the APIC is timing. One characteristic of the ISA bus to PCI bus device in QEMU is to provide timing, but they both provide other things. The interface provides the abstraction or the expressing of a characteristic with this in C:
Code: Select all
struct tclockInfo{
CLOCKHZ curHz;
CLOCKHZ reqHz;
CLOCKHZ maxHz;
CLOCKHZ minHz;
}; typedef struct tclockInfo CLOCKINFO; typedef CLOCKINFO* PCLOCKINFO;
struct iClockClock{
i32 (*GetInfo)(PPRIVATE priv, PCLOCKINFO clock);
i32 (*SetHz)(PPRIVATE, CLOCKHZ hz);
}; typedef struct iClockClock ICLOCK_CLOCK;
The driver provides this since only it knows how to provide it. That is a abstraction.. It could provide multiple abstractions from a single driver instance. The above is a abstraction.
....because not only the rest of the kernel, but every other driver will depend on them.
Okay. So we can not abstract them because they are too fundamental. We should have just realized this because we are talking about drivers which directly talks about the complex device which can not be fundamental since each device is entirely different. Each device can be composed of fundamental circuitry components, but never the less each is individual. You are really saying that the abstraction of the devices is a fundamental abstraction. The abstraction of the devices you are talking about is said as
programmable interrupt controller and
timer. Lets see the entire sentence once more.
There are some drivers ofcourse, which there is no point of sharing. Timers and interrupt controllers are too fundamental to abstract, because not only the rest of the kernel, but every other driver will depend on them.
So I abstracted them, and if I write a APIC driver it will export a
ICLOCK_CLOCK interface for each timer instance on board. Therfore abstracting each one to provide a characteristic or actually multiple characteristics.
The Point Was Really
Ok. So now you got a different point.
You are getting me wrong, on purpose I guess. Point was, that a driver which is nowhere near being functional doesn't necessarily demonstrate much of anything about a driver interface abstraction.
I could have sworn I posted a 8253 driver, 8259x2 driver, and a floppy driver. I think there was sufficient demonstration of abstraction using driver interfaces! What the hell do you mean by,
driver interface abstraction? Is this a abstraction of
a driver interface? How do I abstract a driver interface. I have enough trouble abstracting characteristics of devices using the driver let along trying to abstract the actual
driver interface. I asked you do you want a multi-dimensional warp drive....
Ok. So the floppy driver was supposed to be a abstraction? Did you miss something. Lets go back and see.
There are some drivers ofcourse, which there is no point of sharing. Timers and interrupt controllers are too fundamental to abstract, because not only the rest of the kernel, but every other driver will depend on them.
Where in the world is floppy driver in here?
The only reason I posted the floppy driver was for a example of the
usage of the abstractions.
....
Here is the driver for the floppy I am working on at the moment the point being it is using the abstractions, and the generic idea of it not being too complicated to get a general interface designed.
....
Can you read what I said? Go back to the page one of this thread and find my first post!
And once again there are two fully functional drivers which are actually part of the original topic!
And.. Once Again
Here is the original topic... you wrote it. You should remember it.
There are some drivers ofcourse, which there is no point of sharing. Timers and interrupt controllers are too fundamental to abstract, because not only the rest of the kernel, but every other driver will depend on them. Most will want console output available before even interrupts have been initialized, so that's another thing that needs to be special cased for each kernel (though code is mostly trivial).
So when did my floppy driver become a source of learning or documentation? If you still can not understand this then go read this post again. You said it like I should have never posted it because it was meant to be used as a example of the abstraction. Lets read what I wrote one more time.
....
Here is the driver for the floppy I am working on at the moment the point being it is using the abstractions, and the generic idea of it not being too complicated to get a general interface designed.
....
You can find this one the first page of this thread's post and the first post I made right before the super small code text.
The floppy driver really had squat to do with anything but just a example.
The clock and irqrouter abstract those interfaces even more by providing another interface which is:
Code: Select all
i32 irqrouter_RegisterInterrupt(PPRIVATE priv, IRQHANDLERFUNC handler, u8 vector, u32 flags);
i32 clock_revent(PPRIVATE priv, CLOCKHZ hz_from_now, CLOCK_EVENT_HANDLER handler, u32 flags);
[driver]--->[abstraction]---->[abstraction]--->[thread(kernel/user space)]
The End
So I found you're
last two posts very annoying and completely off topic
with me by means of my intentions in the beginning. I actually felt the real topic avoided and misunderstood while you used the floppy driver as a false argument to something not being abstractable. So get all these floppy drivers out of you head..the floppy driver is not of concern. Leave the floppy drivers in peace. I do not want to hear about the floppy driver anymore. I like that you have figured out how to work the floppy driver, but lets leave that for another place and not this one.
You have switched you're point from:
1. A driver for programmable interrupt timers and programmable interrupt controllers can not be abstracted because they are to fundamental.
2. When the driver is in such a state, I think it's documentary and example value for whatever purpose is extremely low.
3. Point was, that a driver which is nowhere near being functional doesn't necessarily demonstrate much of anything about a driver interface abstraction.
When my original intent was:
1. Here is the driver for the floppy I am working on at the moment
the point being it is using the abstractions, and the generic idea of it not being too complicated to get a general interface designed.
.... There was more than just a floppy driver posted ....
It took me a full day (that's 24h straight, coding/testing/searching for info) last weekend to figure out how the hell do floppy drives actually work. I found the information hard enough to figure out, that I wrote a tutorial about it. That's also why I'd give advice, but obviously you don't want any, and since we are getting into off-topic meta-discussion....actually, now that I think of, that demonstrates exactly why a community project of the kind "let's build a community OS" will typically get nowhere.
No. My opinion is that part of the problem is people like you can not stay on topic. I mean stay on topic. I
loved that you made
a suggestion about the floppy driver which was:
Finally, about your floppy driver... you can't blindly SENSE_INTERRUPT in the interrupt handler, because you can't READ/WRITE with interrupt then, because you get interrupts from those but they have their own result phase and shouldn't be handled with a SENSE_INTERRUPT (in fact, doing so will cause problems in both emulators and real hardware.. I bothered trying this).
Not that your senseinterrupt() will necessarily work anyway on real hardware. You shouldn't read the ports before you've checked that the data is ready, for which you need to poll MSR and check bit7, preferably sleeping between the polling (because the hardware could be slow), which is why it's not necessarily such a good idea to run it from the interrupt handler at all (you could wake up a thread instead).
I hate that the other two thirds of your post was about:
Kevin McGuire: yeah I said in code-blocks, which is much better than not in code-blocks, but if you really want to post lots of code, there's also a relatively decent attachment system. Smile
Have you tried supporting several alternatives in each of those cases? I'm going to claim (without claiming your approach doesn't work) that it's not the first driver for an interface, but the second (or third) that shows if an interface is viable. (say, both PIC and APIC) Smile
Also, have you tried supporting the same drivers in several kernels. To some extend, we need to deal with alternatives for those in every kernel (well every kernel that wants to support wide range of hardware well) but the discussion was about sharing the drivers between kernels. This implies that the whole interface for the driver is well defined, and you never step outside it, because outside the well-defined interfaces, there could be completely different concepts in different systems. The futher complication is that when you add requirements to the interfaces, every time you're going to assume more of the kernel structure, limiting the drivers portability.
But yeah, like I said (after your comment), PIC/PIT wasn't necessarily good examples as such. It's also known that you can solve anything through sufficient levels of indirection. Every indirection level will eats some performance though.
When the driver is in such a state, I think it's documentary and example value for whatever purpose is extremely low.
It looks a little out of proportion and strangely biased towards it will not work because of the floppy driver's state. *shrug*
.
