OSDev.org

hi,
i am developing my kernel in C using gcc. And as it is know OS without using
assembly is impossibly and i have been told that we cannot use assembly (intel
syntax) in gcc, and i am not use to code in AT&T syntax! (and even don't want to).
So is it possible that i can code assembly (inline assembly) in my C Kernel
in intel syntax?
And i want to avoid building seperate pure assembly object files and then
link them with my Kernel , coz i wanna avoid those interfacing problems
which arrive while making C code work with assembly or vice-versa.

Can i code my C Kernel with Visual Studio . i have heard it allows intel syntax.
But will i be able to link that using 'ld'??
Coz i don't think Visual Studio linker will allow me to load my kernel at
1MB mark, and link it with my starting assembly code which sets Multiboot
header etc etc..........

Hi, you can use the intel syntax with the GCC. Just add "-masm=intel".

What about programming Your own OS without C ?
You could use code from my assembler OS, which I just published, written in nasm-dialect ( very close to intel-convention).
Maybe You shorten Your way to Your desires - look at my homepage:
http://www.rcfriz.de
You can contact me at:
[email protected]

Rainer

thank u frizz i will surely have look at ur Assembly OS code. Just for curiosity approximately how many days did u take to code ur OS? But i don't have any intentions to entirely code my os in assembly.
Do u drivers use any Standard Interface? Send me some links for HD, FD controller technical docs. Currently my exams r going on so can't do any OS stuff:(
One last thing ur painting of pluto planet was really GOOD! But does Pluto really look like this?

As far as I know we don't have enough detailed imagines of the surface of Pluto or it's satellite to truely tell what it looks like...

In any event (correct me if I'm wrong) but it doesn't look like frizzz employed a driver architecture with this OS. The floppy initialization is actually part of the OS initialization (ie, the floppy isn't a driver, but is part of the OS).

Are there plans for a generic driver interface?

Cheers,
Jeff

Carbonbased u said :

Are there plans for a generic driver interface?

What do u mean by that? r u asking me a question? or r u saying it sarcastically?
do u know any most widely accepted STANDARD for drivers?
Is UDI universally accepted?

Hi,

kan wrote:Carbonbased u said :

Are there plans for a generic driver interface?

What do u mean by that? r u asking me a question? or r u saying it sarcastically?

I think you asked Frizz "Do u drivers use any Standard Interface?" after he offered his own OS's code, and Carbonbased looked at Frizz's source and found that the floppy driver code was built directly into Frizz's kernel. After that I assume Carbonbased was wondering if Frizz was planning to implement a standard device driver interface.

kan wrote:do u know any most widely accepted STANDARD for drivers?
Is UDI universally accepted?

There is no widely accepted standard for drivers. UDI isn't used by any OS AFAIK (although I might be wrong - there could be a few little OS projects trying to use it).

The main problem I see is that different OS's do things differently, so the device drivers need to be written (or modified) to account for these differences.

For example, for my OS device drivers run as CPL=3 processes that aren't really any different to normal applications. The device drivers use asynchronious messaging, IO port access is emulated, IRQ's are "virtualized". There's other differences for specific drivers too - like storage device drivers need to be able to read/write N bytes at any logical address, where on most OS's they deal with whole sectors only. Printers and scanners are treated like write-only or read-only storage devices (ie. the same as hard disks). Video, sound, keyboard, mouse, etc use completely different device driver interfaces (they communicate with the OS's "user interface" module rather than the "virtual file system" module). Then there's differences in memory management, scheduling, etc that must be accounted for.

Then there's the "device manager", which is responsible for detecting the devices and starting the device drivers. The device manager handles all resource assignment (and can dynamically change a device's resources without telling the device driver). It's also used to stop (and replace) device drivers. When the device manager starts a PCI or Plug and Play device driver it sends the device driver a message containing details on all of the resources that the device driver can use. For other device drivers (legacy ISA devices) the driver needs to tell the device manager which resources it needs access to before it can actually use them.

Given all of the above, the chance of me finding device drivers elsewhere that will come close to working is extremely small, and the chance of my device drivers being useful for any other OS is also very small. Device drivers designed for any OS are going to have similar problems if you attempt to port them to a different OS.

In general, it would also be possible to recycle any other OS's drivers, but to do this your OS would need to contain everything that the other OS's drivers need. This can mean your kernel becomes a mostly compatible version of the other OS's kernel. IMHO this would be a complete waste of time (you might as well use that other OS's kernel and drivers instead of writing your own OS).

To me, this means that the only sane option is to create device drivers specifically for your OS.


Cheers,

Brendan

kan asked me, if the surface of pluto really looks like my picture. When You go to my homepage again, You will find a link below the picture to a second page, where I explain, why my picture is truthfull. You can find a picture shooted by a space-probe, which visited ganymed - an ice ball too, but a moon of Jupiter. You will find such ice-collars around a hole on a real photo.

Now to the FD-driver:
There is a "standard", because every FD-controller in an AT-PC is compatible to the old 8272. But it does not contain a FIFO as modern 82072 and derivates. That's why I "halt" in my OS, if an old 8272 is detected ( initialization therefore needs to be a part of the bootloader).
But You will find 82072-controllers in a lot of other machines too.
I wrote my drivercode new from scratch, because I wanted to omit programming of that odd DMA, which does not transfer directly to memory above 1M. As far as I know, my "PIO-mode" for FD-access is the first reliable code. It was really hard to do, because it isn't documented in every detail. I.e. You need to take a certain errorcode as signal for success - else You will never succeed...costed half a year to code, test and debug that code.
But Brendan is right - I did not intend to standardize FD-drivers. I standardized my driver for my OS (and future derivates) only. There are some decisions to find (as Brendan mentioned very detailed) for interfacing, and if You intend to use my code, You need to read the source very carefully. My decisions are:
> PIO instead of DMA
> not to adress single sectors - tracks only
> automatically eoi - if You do not know, what that is, read docs about the interrupt-controller. This device needs to know the eoi-condition (end of interrupt). Normally (in BIOS, M$DOS,linux) there are commands wasted to tell the controller the eoi, which can be omitted by setting "automatically" eoi.
> memory-source or -destination is a segment ( selector has to be in fs !)

As Brendan is right, that the only sane way is, to write Your own driver-interface, You will have to make Your own decisions. But You could use the most of my code, because every command sended to the FD-controller and every sequence of I/O and every timing will be the same in every case (that's why I called it "standard").

If You intend to do first steps in assembler programming, You will find a reliable tool in my OS. It is well commented to tutor beginners. A lot of "utilities" are menupoints or procedures and code sequences, which You can easily use in Your own code (added to the program). If You add an interrupthandler, acting as an "operating-system-interrupt" similar to int 21h in M$DOS or int 80h in linux, You could use the drivers in my OS in Your own program, started with my OS.

But this OS is only a first step to ( and finally an install-tool for) the mature OS, which is under construction. Such a mature OS ("kernel") contains further decisions about a filesystem, memory-management, program-starting, device-driver-interfaces a.s.o....
As You can see in my published baby OS, there are a lot of things, which can be omitted, if You do not desire multi-everything (reasoned once in stone-age by limitations of memory space and needed "mainframes"). If You use indexed adressing in Your programs (drivers and applications), You can find a very short way to a "fully featured" OS without MBytes of code and GBytes of docs, which are reasoned by the use of C/C++. "Higher" languages do not allow indexed adressing. In my code You will find a lot of examples, how useful indexed adressing is in jumps and calls (i.e.for switching from edit- to menu-mode).

Doesn't automatic EOI allow the possibility to fire the next IRQ while you are still processing the first one (race condition)? As this is what it sound according to all descriptions.

And what about modularization?