Subject: Re: fbset 2.1, .49, various stuff
From: Samuel Rydh (samuel@ibrium.se)
Date: Mon Jul 31 2000 - 09:40:38 MDT
On Mon, Jul 31, 2000 at 12:16:35PM +0100, Michel Pollet wrote:
>
> Hi there,
>
> I just started to update myself on linux ppc hacking once again, and I
> played with MOL too.
>
> I'm using the MOL .49 which is in the BitKeeper tree, and I have a few
> remarks / questions.
>
> + When is that tree updated ? seems it has been stagnant for a couple weeks?
Well, I pushed major changes to the networking layer some hours ago.
I have a few other things in the pipeline (interrupt driven
sound, improved block driver and eventually a serial driver).
> + Where do I send patches ? The List ? Samuel ?
To me, or push them directly to the BK tree (those of you
who wish to obtain write access to the BK tree, please contact
me).
> + Seems MOL doesn't handle the new options in /etc/fb.modes version >= 2.1.
> new lines have "accel true/false" and "rgba". Has anyone fixed it or should
> I ?
Please go ahead.
> Now, getting bugged by Ben to hack stuff in MOL, he asked me to make the
> clipboard work between X & MacOS. it is not very tricky to do with the OSI
> interface thing, but I was wondering if anyone plan to have a TVector patch
> mechanism, to allow to do "quick patches" from MOL instead to have to write
> a driver/INIT for that kind of stuff.
>
> Maybe make a generic driver that allows registration of OSI function to be
> called on specified TVecs...
That would be neat. The main problem is argument passing
(the linux side needs physical addresses and physically
continuous memory). Moreover, there is the problem with mac
header files on the linux side (they don't compile well since
gcc does not like 68k alignment. I'm also uncertain whether
it is legal to include the headers in the mol source).
> I've also been discussing shared disks, and how we might pull that one off.
> Basic problem is file system format - being independent, or not -
> Basic possibilities were:
>
> + Using a netatalk base:
> Would involve stripping netatalk of anything related to ethertalk, use the
> ASIP API on the mac and the ASIP/FS API from netatlak on the host to
> simulate disks. Those netatlak bits would be embeded into MOL.
> + Having an 'external FS' on the mac (aka, MountX) which encapsulate
> everything into OSI call to access the hosts FS. Problems is that it
> wouldn't handle "easily" mac specific junk (resource forks).
Another possibility is connecting to netatalk via the tap0 or eth0
device (this works with the new network drivers). The problems
with this approach are:
- the ethertap module must be compiled with multicast support
(we might consider bundling it with MOL).
- eth0 does not work well if not attached to a physical network
(in this case the tap device should be used).
- to use AppleTalk on both tap0 and eth0, netatalk must create
a new zone and route traffic. This is not particular difficult to
configure, but the address ranges should be cleared with the
local network administrator. Also, creating zones in a
previously flat network might require that connected
servers/printers are rebooted.
However: If the machine is connected to an ethernet network,
netatalk should work out-of-the-box.
So, the big question is whether it is worth the trouble
or not to implement a shared filesystem spcifically for
MOL? It would certainly be nice to have one...
Cheers,
/Samuel
----------------------------------------------------------
E-mail <samuel@ibrium.se> WWW: <http://www.ibrium.se>
Phone/fax: (home) +46 8 4418431, (work) +46 8 7908470
----------------------------------------------------------
This archive was generated by hypermail 2a24 : Mon Jul 31 2000 - 08:47:00 MDT