On Wed, 28 Jul 1999, Ken Nakata wrote:

> On Tue, 27 Jul 1999 22:08:44 -0700 (PDT), Alex Zepeda <garbanzo@hooked.net> wrote:
> > On Wed, 28 Jul 1999, Ken Nakata wrote:
> > 
> > > > If you don't mind GPL'd code
> > >
> > > The thing is, we do ;-)
> > 
> > Sure, but as a stopgap measure..
> 
> No, I was talking about GPL'ed code within kernel which violates a
> (written, I think, though I don't remember where) policy of NetBSD.

GPL'd code in the kernel generates a kernel which can not be legally
re-distributed under the terms of the GPL. That's the problem with it. :-)

> > > That could be a solution, but it's inherently MD (i.e. mac68k specific
> > > - since no other port, perhaps except macppc, needs that).  I kinda
> > > hate that.
> > 
> > 'Course the kernel is going to be MD :^)
> 
> The kernel binary itself will be MD, of couse, but hfs layer can be
> and should be MI.  Sysinst, it seems to me, should be as MI as
> possible.  Creeping a mac* specific feature into sysinst doesn't sound 
> right to me, but I'm no sysinst expert.

Right. Whatever hfs support we add should be available to all ports. :-)

> It just seems to me a little cleaner if sysinst can mount local HFS
> partitions and read dist set files off of them (just as it would mount
> an ISO9660 CD-ROM and read dist set files off of it), rather than
> invoking an external program.  Well, maybe there's not much difference 
> since we already do that with ftp and the likes.
> 
> Besides, with in-kernel HFS support, you may one day be able to export
> your HFS partitions over the network with netatalk.  It sounds like a
> win to me.
> 
> BTW, are netatalk and CAP different in treatment of the resource fork?
> I vaguely remember CAP looks into .resource/file (or s/t like that)
> for file's resource fork (my college uses CAP to export UNIX home
> directories to Macs).  Oh, well.  I think I'm asking this question way
> too early.

netatalk and CAP do treat the resource forks differently. Paul Hargrove's
hfsfs will actually export the resource forks differently as per mount
options. :-)

Take care,

Bill