[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Supervisor mode & multitasking



draco@piwo.bl.pg.gda.pl%INTERNET wrote:
> 
> > And besides: what exactly do we get
> > out of that change? Could you please give an example? Eric had his
> > reasons not to touch that behaviour...
> 
> I think I did an example? I.e. such a program like networked BadMood. OK,
> this is a game ("no need for such a software"). So generally: supervisor
> multitasking would make the system run more smoothly. Now any disk access
> blocks everything. This is generally sad, when you gonna try to work in a
> text editor having a program which is searching for something on a

So why then do we have background DMA transfer in MagiC (I know you
don't like to hear that...) without having MagiC taskswitch in
supervisor mode? Because MagiC addresses this issue with a small set of
kernel callbacks to which harddisk drivers can easily hook to.

BTW: non blocking disk accesses (as far as I understand) also require a
fully reenttrant system (trap dispatcher -> filesys -> filesystem
driver...). I think there's a lot work to do on MiNT and tosfs.c to get
there.

> filesystem in the background. Also s3mod is practically unusable for this
> reason. Flow text output to the console also practically blocks (like
> disposed cat /dev/ttyb while a computer at the other side of the cable
> keeps sending junk via RS-232) and is impossible to abort using Control/C.

This example I really do not understand. They seem to be problems in
some specific applications...

> FInally, if a program enters suprvisor mode and crashes, there's no way to
> get control back on the system. More examples?

Hmmm. What has that to do with the question whether there should be
taskswitching in supervisor mode? Besides, I don't agree. If a process
crashes in supervisor mode (be it because it calles Super or Supexec, or
because it called the kernel) it is terminated. Just in user mode.

> I really would like to know what your personal problem is.
> 
> Being sad person you never gonna understand it.

I don't think that lines like this contribute to your credibility.

> > Somebody asked me about information about XFS programming, and I pointed
> > him
> > exactly to the place where *I* got my information from -- meaning all
> > the
> > example XFS code in MiNT. And small XFS modules like procfs.c are very
> > readable.
> 
> There's no need to discover everything twice or more times. If one knows
> something, there should be no problem to him to give out this knowledge as
> a comprehensive doc or (as it was requested) as a skeleton XFS. I've
> personally never had a problem with giving people the full possible
> information, according to my 8-bit or ST computing knowledge, if they
> asked something. I've also never had a problem telling them "I don't
> know", if I wasn't able to answer the question. So I can't understand your
> tendention to give laconic, meaningless responses to any question you're
> being asked. But this is really your problem.

First of all, it makes a giant difference whether somebody asks a very
specific question (that I would be happy to answer if I know the answer)
or if one is ask to basically produce a new document or new source.
Second, i reffered to the numerous XFS examples in MiNT itself just
because *I myself* found them useful when I implemented my XFS. 

Regards, jr