"Adding" HFS+ support to A/UX

Just did a search and Yellow Dog Linux mounts HFS+ partitions fine (read and write). So this has been done (on the kernel level I assume).

IC

If you have the kernel headers for A/UX (and assuming it's somewhat like the linux kernel) you might theoretically be able to compile an HFS+ kernel module for it. I'd say it would be very difficult in any case if not impossible.

that is really out of the picture for the obvious reason you stated. But could a separate application be written to handle HFS+ similar to what someone seems to have done for HFS? Maybe that would only mount the drives and not allow for any ready/write (I don't know what that piece of software allowed) but theoretically, the same should be possible for HFS+. Right?

IC

Linux HFS+ support is just fine. It's recommended that you use OS X on HFS+ to turn off Journalling. Otherwise, it should work fine. Thus, if you use the Linux HFS+ code and make something that can handle the device setup in A/UX you should be fine. UNIX was designed to be easy to work with. That's why all system devices can be treated like files through /dev entries. If you can't write a kernel module, then you write a user level app that makes calls through a /dev entry and have at it. It's a bit more complex than that, but by design it's easier than banging the hardware and hand coding assembly to get it done.

Just curious, couldn't an app be created to mount an HFS+ partition as a network drive or something along those lines? make the system think its accessing it over ftp?

Why? By the time you built-up the software to be able to read and write to HFS+, you might as well let it work as a normal device driver. There are old tools that read and write to HFS partitions by using special commands. They were basically there as a stopgap to make developing the HFS routines easier, without worring about keeping up with kernel version changes. Now that HFS support is available in open source software, getting the support routines is easy. It's getting the system level integration that is tougher. That's why I mentioned the /dev entries earlier. Under Linux you can access a specific hard drive with /dev/hda, /dev/hdb, or a specific partition on that hard drive with /dev/hda1, /dev/hda2, etc.. You would point the HFS+ software at what ever the /dev spec for the hard drive is under A/UX, and let it work. By using special tools the get to the partiton, you are at the mercy of what ever the commands can do. Once a kernel level module is made such that the HFS+ partition can be mounted, all normal system tools should work, as the HFS+ filesystem should be able to be mouned in the filesystem tree as would any other useable filesystem.

EDIT: By-the-by, does A/UX have UFS support? It's the file system used by DVDs, and OS X can use it to install to. I know later versions of Mac OS have it, for DVD support. If it's not native,t hen has someone made a kernel module for it, and could you use that info as a base for applying HFS+ code for a new module?

Just for the record here, the DVD filesystem is *UDF*, not UFS.

http://en.wikipedia.org/wiki/Universal_Disk_Format

I've seen this misconception repeated several times here. The two are *not* the same.

A/UX natively uses a variation of UFS:

http://en.wikipedia.org/wiki/Unix_File_System

like Free/Net/Open/WhateverBSD, Solaris, HP-UX, etc, but UFS interoperability between platforms is pretty poor.

As for adding HFS+ support to A/UX, well, if you have sufficient documentation at hand you *might* be able to do it. Maybe. The only documentation I could find about that HFSMount program is in this This ancient mailing list post. Gunzip on my modern computer won't work to uncompress the archive itself to see if there's any more documentation inside it. However... this is just a guess, but reaching into the hermetically sealed mayonnaise jar on the Funk and Wagnalls front porch of my mind tells me that what this program *really* does is force a rescan of the SCSI bus so the running MacOS layer in A/UX will detect and mount HFS drives that weren't active at boot, and that it *doesn't* actually act as a plug-in filesystem for mounting HFS drives on the UNIX side. Again, that's purely a guess, but the mailing list entry's saying that it's a *program* to run once as root boisters that suspicion. (You'd think he'd be substantially more proud of his effort if he'd actually written a full HFS filesystem kernel module, particularly since this is better then half a decade before any open-source OS came along with HFS code to steal.)

Honestly, I suspect A/UX doesn't support loading a filesystem as a module. It's an *old* monolithic kernel OS. Feel free to prove me wrong, of course. You *probably* could make a stand-alone HFSplus "client" program work, assuming A/UX makes "unknown" partitions available as raw devices under /dev. Try porting the old hfsplus utilities:

http://penguinppc.org/historical/hfsplus/

They're akin to the "mtools" program for copying files on and off DOS filesytems under Unix without actually mounting them. Since they operate at a user level you should be able to make them work without kernel source. Of course, this code has been rotting for a few years, since hfs+ support was sucked into the linux kernel proper, so you're likely to encounter problems. You might want to see if you can make the better supported "hfsutilities" work first:

http://www.mars.org/home/rob/proj/hfs/

Anyway, good luck.

--Peace

In reference to my last comment, apparently hfsutils already works on A/UX:

http://www.gatago.com/comp/unix/aux/2483040.html

So I'd say there's no doubt with some work you could make the hfsplus utilities go. That's still a country mile from getting it into the kernel, but, well, there you go.

--Peace

getting it into the kernel is academic... but only after it has been somehow transformed from an executable (assuming you find the source, and compile it into an A/UX executable) into a valid kernel module. Compiling a new A/UX kernel is no big deal. I'm only posting because the feel of this whole thread insinuates that making a new kernel for A/UX is hard or something. Its not. But creating a kernel module might be just difficult enough to make your eyes bleed.

and good call on the whole UDF vs. UFS thing... its crazy confusing, no?

Just to note, "newconfig" *builds* a kernel, but it doesn't *compile* it. It slaps together existing precompiled driver modules and hardcodes some sysctl values. A/UX does *not* include the full source code for the kernel proper, and adding support for a new filesystem to a UNIX kernel is considerably harder then adding a new device driver unless the kernel in question specifically supports plugging in filesystem modules. Something tells me A/UX doesn't (again, could be wrong here, but I see no evidence that anyone ever wrote one), and if there's no exposed API for doing it then you're *not* going to be able to do it without the full kernel source. (And probably some serious hacking.)

The only route I can really think of taking without the kernel sources is something really back-a*sward like writing a userspace daemon that "mounts" an HFSplus partition and emulates something A/UX *can* mount. Perhaps have it emulate an NFS server, which you'd mount from localhost. In principle you could mount just about any filesystem with a userspace driver that way.

--Peace

Hmmm, this is getting interesting. How about this here then:

http://fedoraproject.org/extras/4/i386/repodata/repoview/hfsplusutils-0-1.0.4-5.html

This "might" then work with minor changes (I haven't taken a look, will soon).

Thanks for all the input, I'm learning a lot here (which means that I could probably never write anything that would actually work).

IC

thanks for pointing this out... I was under the impression that the modules were source, but I see now that, say, compiling a linux kernel from source all custom tricked is not at all the same as building a new kernel in A/UX