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

Re: [MiNT] [PATCH] Export function XHNewCookie to kernel modules



2010/12/13 Vincent Rivière <vincent.riviere@freesbee.fr>:
> XHDI seems to be by nature TSR stuff: it adds a cookie with functions that
> can be called by any program from supervisor mode... not really clean MiNT
> programming (from user mode programs).
>

OK we have a specification that from the MiNT point of view isn't very
clean but I think the kernel tries that things to be not so bad and a
bit cleaner. This is from an old list thread, all written by Frank:

" That's why the kernel overwrite the XHDI handler by a system call wrapper.
 XHDI calls from user space applications are redirected to a system call and
 handled inside the kernel (privilege checking, restricted to root). So XHDI
 is no problem."

> So extending XHDI by adding a hook (XHNewCookie or other) from TSR-land to
> some kernel module seems to be a bit insane...
>

>From the same old thread:
"No, the driver is started before MiNT and thus per definition part of the
kernel space. But for sure I'll agree that a source integrated driver is
much better :-)"

So TSR-land is kernel space so things may be aren't so insane.
Also I don't know what exactly means "source integrated driver" for me
it means a disk driver integrated in the kernel sources as part of the
binary or module, and I guess he's talking about a XHDI driver. So it
looks he didn't think that XHDI driver was a TSR thing by nature.
Because it was said by Frank doesn't mean it has to be right, but he
knew much more about the kernel than me.

If someone wants to see the context of the mail, here is the link,
subject "virtual address spaces"

http://sparemint.atariforge.net/mailinglist/Mailing-Lists/MiNT-List.200512/Index.html

Now the alternative we have is to put the mass storage driver in to
the AUTO folder, let's suppose we already have a USB core as module
and different modules for USB classes and USB device drivers. But for
the mass storage class we should put the driver as a TSR programm in
the AUTO folder, the first problem I find is how I communicate from
the TSR with the USB core, Is right to use the USB user space API that
is planned? or I should create a new interface for this specific
situation (TSR communicating with the USB core)?.

I'll do whatever we agree, but the alternative solution makes my live
harder ;-), and I guess it will make the development slower.

I'm all ears :-)

David