OSDev.org

Dragon_Hilord wrote: @kataklinger: Is that just the cost to regester the name and such, or is that just to get a permit of some kind?

It's a cost to register the name and after a few days you can start working (and paying taxes )

hahaha. Tax. Love you government

let's see. The closest I could find to here (New Brunswick) was Nova Scotia (close enough) for all of the prices :

note: all money in CDN Dollars!

• Partnership: $50
• Incorporating: $335 to regester. $85 annual costs
• Incorporating in NB: $260. ?? annual
• Finding a name in NB: $45 (to id overlap)
• 5yr Business cirtificate in NB: $110

Cheers, DH.

A few things to say about this:

1.If we think it can be done and are willing to do it, I will help. I may not be able to help MUCH, but I will help.
2.I second (third?) Solar's vote for implementing UDI. Uniform drivers help everyone. In fact, I was planning on UDI for my one-man project anyway, so if we decide to implement it I can help with it as I code it for Glider.
3.An official governing structure really isn't needed too much right now IMHO. If we ever need one it should be based on voting.

Crazed123 wrote: A few things to say about this:

2.I second (third?) Solar's vote for implementing UDI. Uniform drivers help everyone. In fact, I was planning on UDI for my one-man project anyway, so if we decide to implement it I can help with it as I code it for Glider.

UDI does sound like a good idea... I'm not sure how many drivers exist for it, but I'd be willing to help create some. For myself, I consider UDI not good, but I can't explain why.

>I consider UDI not good, but I can't explain why.
Same happens to me ,perhaps because nobody uses it?
Some important manufactures designed UDI ,but if i?m not wrong they didn?t write any driver using it. If even their autors don?t use it ,then it must be really bad.
Is like if i designed Octasm without writing a single line of code with it.
To SOlar:
I was talking about something more general, for drivers,filesystem and aplications, not only drivers.And also something simpler, i don?t like to read a 1000's pages pdf every time i want to code something.

I would use UML for documenting and planning, word cannot explain everything.

UML is a method of designing, Word is a word processor, they're not mutually exclusive. I've done plenty of UML diagrams in Word for random courseworks. Of course, if they get very complex something else is more appropriate, assuming you have the rest of the Office suite then Visio would be an obvious choice, One Note is worth looking at though.

Or just grab a free tool from somewhere ;D

Sorry, I didn't meen to say "Word" I wanted to say "words" ;D
Diagrams can explain something that words can't explain that easy (and UML is standard for that).

And why would some one thinks that these two things mutually exclusive?

Or maybe Rational Rose Proffesional? ;D

Try Dia or Umbrella for free Visio alternatives.

Oh and people, don't send me closed-filetype-spec files. Try using an open format for most things.

Lol, sorry, I thought you did actually mean Word ;D

Try Dia or Umbrella for free Visio alternatives.

Do these tools has code generation feature (for C++ & C#)?

Visual Paradigm is great (and ther is a free version of it), and can be integrated in MSVS.NET and Eclipse.

I've been using Poseidon UML, but it's @#$)(* slow on my 6-year old 800MHz processor... >:(

I've tended toward a whiteboard and pieces of paper for my UML design thinking. When I'm done I can enter it in Dia and print it out with nice formatting, and after that I can type my code for it.

Generating code? Very very likely going to take me just as long to adjust to what I like.

Hi,

Candy wrote:UDI does sound like a good idea...

In theory, the concept of standardized device drivers sounds extremely good. In practice any possible standard will rely too much on the overall OS design to allow that standard to be used for all OSs.

Consider a simple device, a parallel port device driver for example - bytes are sent, bytes are received and there's not much else. A common device driver sounds easy..

First step would be resources. For some OSs, the I/O ports used by the device driver would be specified at compile time, for others there'd be command line options used when the device driver is started. Maybe it gets this information from a configuration file instead, or perhaps some other software (like a "device manager") sends this information to the device driver via. IPC.

Once it knows which resources to use, does it have to "allocate" them from the kernel or is this done for it (or not necessary)? If it does, can it send a list of resources or does it have to allocate each individual resource one by one?

What happens when the computer has 2 almost identical parallel ports? Is the same driver started twice, or is only one driver started that handles both parallel ports. If only one driver is used, does it spawn an extra thread for the extra parallel port, or does the same thread handle both devices? Does the device driver use threads at all?

How does software that wants to use the driver know how to find it? Does the device driver create an entry in the file system (e.g. "/dev/lpt0") or is there a different method used, like named pipes with a different namespace? Does the device driver autodetect what hardware is plugged into the parallel port and start the device driver for the printer (e.g. plug & play standards), or does it tell some other code that another device is present (e.g. notify a device manager that takes care of it), or is the auto-detection done elsewhere?

When some software wants to send some bytes through the parallel port (after establishing a connection to the device driver), does it just tell the device driver the address of a buffer and how many bytes to send, or does it need to send these bytes to the device driver over IPC, or does it need to negotiate a shared buffer beforehand? If software wants to send 23 MB of data to the printer (a high resolution photograph or something), can it all be sent in one go or does it need to be split into several smaller transaction. If so, how is flow control handled?

How about when bytes are received - does the device driver send a message containing the received data, or does the device driver put the data in a buffer and wait for someone to read them from the buffer? If a buffer is used, where is it - in client-space or in the device driver's space, and what happens if it overflows?. How does anyone know bytes are available to read - is polling involved or some sort of notification? Would the notification be a callback or IPC?

Now imagine you're trying to develop a device driver standard that is meant to be suitable for all OSs. As soon as you make a descision on any of the things above, you've limited the standard to a specific kind of OS. If you allow for all possibilities (e.g. if the standard supports every option above), then you'd end up with an unusable mess. If it's this hard for something simple device like a parallel port driver, how many problems do you think there'd be for something more complex, like a USB controller or video card?

Candy wrote:For myself, I consider UDI not good, but I can't explain why.

That's called "intuition"...


Cheers,

Brendan

Reading the spec, I think the opposite is true. UDI is so generalized that it will be annoying as hell to work with, but any OS could reasonably implement.