On Sun, 06 Jan 2002 12:57:12 -0500, "ZN" <[EMAIL PROTECTED]> wrote:
> On 1/6/02 at 7:32 AM Thierry Godefroy wrote: > > [PCI on the QL] > > >> the problems are QDOS specific... > >> ...Not many people around who have the thorough knowledge about the > >> hardware and software to write more complicated drivers. > > >True, but knowledge can be acquired by anyone, the problem being the time > >needed to do so... Note that most of the knowledge to acquire is NOT > >QDOS/SMS specific, whatever driver you are going to implement on whatever > >plateform, you need to learn about protocols, standards, etc... > .../... > > Thierry made several good points. Of course, many will not find them as > valid if they come from a standpoint of modifying an existing driver (and > recompiling it for a speciffic platform) rather than building one from > scratch. Note that for the CDROM device driver, I did consider to adapt Linux sources. But while digging into the Linux sources, I quickly understood that this would lead nowhere... > The way things are done under SMSQDOS (assuming you have divined > this 'from the source' :-) ) actually makes attempts at converting existing > drivers (unless they already come from SMSQDOS) quite unproductive. This is EXACTLY what I finally concluded in the CDROM driver case... Therefore the only sensible approach was to write everything from scratch with the actual ATA/ATAPI/ISO specs as the reference. .../... > >The problem is rather the lack of professional programmers that could > >actually work full time on QDOS/SMS... TT is not the only man that > >can write device drivers or OS extensions for QDOS/SMS, there are still > >talented programmers around, but none of them are able to spent signifi- > >cative time (i.e. a few months - full time) on QDOS/SMS software > >development... > >Now, with some good motivation, most of these programmers will be ready > >to "sacrify" significant part of their free time to do some software > >development. > > The equation is very different if a huge potrion of that time, or even MORE > than that time is needed to first reverse-engineer code. Doing that is far > more time consuming than actually writing working code. Exactly ! It is rather painful to have to reinvent the wheel everytime (this is the reason that made me decide to make the ATAPI/CDROM things sources open: at least if my method of implementing a driver works, then someone else will be able to use it in another device driver). > In light of the comments regarding access to SMSQ/E source code, it begs > the question: what would it take to BUY the source code from Tony Tebby? A lot of money I guess ! ;-) > Or, some kind of licencing agreement that would effectively have the code > in the open but with someone as the 'code cuistodian' - i.e. it would not > be freely distributable, rather under something liek a GPL. I really don't think TT would be ready to GPLize his OS ! By GPLing a source, you loose all control on what it will become (for the best or for the worst). This is why I choosed the "Artistic license" for the ATAPI/CDROM things: at least I can keep some control on what the code becomes... > > New hardware (INCLUDING UNSUPPORTED ONE under QDOS/SMS) is a very good > > motivation as far as I am concerned... IF a new 680x0 board with PCI > > bus is built, then I could well find enough motivation to write a bus > > initializer for it... > > Which, of course would be the first 1% of the job since something has to be > plugged into it, and that's when all the fun begins :-) Yes, but I like to have "fun" ! :-) > >The old debate "should software be designed before hardware ?" is a > >nonsense to me: IF there is hardware I can test software on, THEN I > >can write software for it. > > Actually, it's a kind of chicken and egg argument. For some hardware to > actually start doing ANYTHING usefull it has to be initialized. > .../.. OK, but to test hardware you do not need a full functional OS ! Your bootstrapping code may therefore be more crude... Once it is possible to bootstrap some code, then the actual and definitive initializers/ drivers development may start... QDOS/SMS forever ! Thierry.
