> Hi!
>
> > Jan Kratochvil wrote:
> > > P.S.: When we're at another large memory copying, will someone the write page
> > > flipping support so that during CD burn the data will no longer be copied
> > > 6 times? Count with me:
> > >
> > > [disk DMA->kernel buffer]
> > > 1. buffer -> userland mkisofs
> > > 2. mkisofs -> kernel pipe buffer
> > > 3. kernel pipe buffer -> userland buffering tool
> > > [>10MB buffer to deal with starvations during compiles]
> > > 4. userland buffering tool -> kernel pipe buffer
> > > 5. kernel pipe buffer -> userland cdrecord buffer
> > > 6. userland cdrecord buffer -> scsi layer buffer
> > > [scsi layer->scsi controller DMA]
> >
> > To get this to work better, you could:
.....
If I remember my OS's at all QNX uses token-passing instead of actually
recopying memory (as do some other RT OS's). Why can't this be
implemented in Linux? [I've been working on a userspace form of this for
message passing at high internal speed.... need _FAST_ graphics calls to
get queued to graphics thread ASAP so thread doesn't end up sleeping most
of the time]. I can't see why it couldn't be implemented in kernelspace
(only possibly using buffer copying <-> DMA memory when actual
memoryspace is not available to DMA device). Security though? Dunno.
Apparently QNX doesn't have a problem with this (but I'm going with old
DDJ articles [canna remember which issue] and sales gunk from QNX).
Shared memory-based token passing with full SMP support isn't difficult
to implement - just time consuming <ouch>. Haven't a clue if my stuff
could work in the kernel (and I won't have time to check it for a few
days whilst I try to catch up to the current kernel).
FWIW - I use a single processor 486 system. I just believe that any code
built for one processor should either be SMP-friendly or easily rebuilt for
SMP.
[also I seem to have a dead motherboard or something - Linux crashes
1/day and no other OS survives longer than 5-15 minutes [Win97, WinNT 4,
DOS]]. I have SERIOUS respect for Linux 'cause of this....]
(I don't get paid well enough to buy a new motherboard/CPU/floppy disk/...)
Quick vote:
If anyone goes about putting efficient token-based message passing
into the kernel - please make a user-open equivelent (or back-callable
so that messages can be passed between threads)!!!!!!
Also:
- Is FAT32 support around yet? If not, any ideas where I could start?
(the FS fascinates me - I don't actually have the space to
build a FAT32 partition though)
- is the Win95+ CD-kluge handleable? (they use a different
system for storing long names on burnt CD images and I lost
the names for the backups for my system 'cause they were burned
by Windows/95 <grrr!!>)
[Not by me - I woulda kluged _ANYTHING_ together to burn
nice standard ISO-format+RockRidge CD for Linux]
> > Of course, the ideal would be to DMA directly from the disk
> > to the CD across the PCI bus. Hey they might be on the same
> > SCSI controller, then the data never has to leave the
> > controller... :-).
> :-) Are the current SCSI disks so smart so they are able to be commanded
> to intiate connection disk->cdwriter? I don't think so... Especially
> various cheap IDE-like disks...
SCSI drives ARE intelligent enough for this.... and they are _FAST_ when doing
this!
EIDE isn't smart enough, but SCSI could handle it in the first version.
[it's up to SCSI-III these days isn't it?]
.... of course just 'cause the standard allowed it doesn't mean any
manufacturers actually _SUPPORTED_ it.
Ciao!
- Teunis
... though I have yet to encounter a SCSI drive that does NOT support
direct controller-moderated device-to-device transfers. (does Linux
support this? OS/2 did on my controller (Adaptec 1542B) since 2.0)