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

Re: [MiNT] patch:MiNT:KM_FREE



On Mon, Dec 14, 2009 at 5:34 PM, Helmut Karlowski <hk10@gmx.de> wrote:
> Am 14.12.2009, 07:24 Uhr, schrieb Paul Wratt <paul.wratt@gmail.com>:
>
>> is this one part of the KM that need to be reworked. I would say a
>> file pointer should be enough, but only if its "siganure" says its not
>
> run_km should return some value, that can be referred to later. I don't know
> how to do this.
>
> Just filename sucks, but before it was even worse.
>
>> already loaded. Can the filename be used in combo with app_id, or is
>> that strictly AES only..
>>
>> What circumstance should it be possible to load two modules that are
>> the same. Certain other kernels do allow this if the KM handles
>> multiple "things".
>
> Future!
>
>> I thing there may be a need for a functioning KM skeleton (or similar)
>> to allow co-exist, order and unload testing, including km reloading
>>
>> would a modprobe type tool for MiNT be of any use?
>
> What's that?
>
modprobe is a *nix comand line tool for querieng and dynamically
unloading and loading kernel modules

Is it possible to allow for both KM reload, and specifically with
reference to XaAES, to unload current KM, then load a new KM (with a
different filename). Or is there some reason why this should be
restricted to implementation in xa_loader.prg only.

Both of these would make it possible to change certain aspects of the
OS that should not require MiNT to be rebooted.

do KM in the context of these and other threads, not constitute XIF,
XFS and XDD at least from the kernels point of view, and if not, why?
The only difference noted here is that they are hardware and/or
drivers, and XaAES is not. AES is technically a driver that abstracts
visual display/desktop, in the same way hardware drivers are an
abstraction of the hardware.

Currently can  XIF, XFS and XDD be unloaded and loaded after the boot
process, and if not, why? The process for all should be consistent, if
for no other reason that at some point in the future some one will
want to build a KM that clouds the line between hardware driver, and
software driver.

Paul