Jeff Bailey | 20 Apr 2002 04:20

Re: ioperm

On Sat, Mar 23, 2002 at 09:19:10PM -0500, Roland McGrath wrote:

> * sysdeps/mach/configure: Regenerated.

I'm trying to test your ioperms patch so that I can get items off my
todo list, and I've never had to regenerate these before just in a
subdirectory.  I tried the obvious 'autoconf', to be given:

autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_FD_MSG
***BUG in Autoconf--please report*** AC_FD_CC
***BUG in Autoconf--please report*** AC_FD_MSG
***BUG in Autoconf--please report*** AC_FD_CC
***BUG in Autoconf--please report*** AC_FD_CC

8< (snip)

What's the trick? =)

In the mean time, I'll hack around it.  I think I can guess what the
right thing to replace these with is from the other configure files.

Tks,
Jeff Bailey
Roland McGrath | 20 Apr 2002 04:25
Picon

Re: ioperm

The libc makefiles should do the necessary thing for you.
Roland McGrath | 23 Apr 2002 06:23

Re: killing serverboot

> With a forced upgrade for all users, perhaps now is a good time to
> remove the compatibility code from GNU Mach.  Comments?

I don't see a reason to remove code that works and we aren't spending any
effort to maintain further.  We can remove it from oskit-mach (which we
could start calling 2.x).
Neal H Walfield | 23 Apr 2002 06:26
Favicon

killing serverboot

With a forced upgrade for all users, perhaps now is a good time to
remove the compatibility code from GNU Mach.  Comments?
Marcus Brinkmann | 24 Apr 2002 04:44
Picon
Favicon

Re: gnumach release

On Wed, Mar 06, 2002 at 06:41:32PM -0500, Roland McGrath wrote:
> > The current Debian packaging of the Hurd does not meet recent Debian
> > standards.  I can take a look at that when I'm back.
> 
> Marcus, can you take a look at the gnumach debian packaging and make sure
> it's all good?

I have fixed a small bug, except that I am happy.  We don't follow Debian
policy to the letter, but by the time anybody cares about that policy will
be fine again (the symlinks from /usr/doc/ to /usr/share/doc are missing,
but they will be dropped soon anyway).

There is really nothing holding back a gnumach release from my side.

Thanks,
Marcus

--

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd <at> debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus <at> gnu.org
Marcus.Brinkmann <at> ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Jeff Bailey | 24 Apr 2002 05:36

Re: ioperm

On Sat, Mar 23, 2002 at 09:19:10PM -0500, Roland McGrath wrote:

> Here are libc patches to add sys/io.h and ioperm a la Linux, using
> Marcus's new Mach interfaces.  Please test this and once it works I
> will put it into libc.  This is from my 2.3 tree, and you will need
> a slightly different makefile hack to get mach_i386 stubs built in a
> 2.2 tree; just hack the interface list in mach/Makefile, and I will
> clean it up when I put it in.

Oh hey, I should read the comments when I'm applying patches.  (This
explains why my new glibc has no ioperms function...)

I'm having trouble figuring out exactly what to put in this Makefile.
There isn't a good example to follow for something that's sitting in a
sysdeps directory.  Would I just add "ioperms" to this?:

user-interfaces := $(filter-out mach/mach_interface \
                                mach/mach_port mach/mach_host mach/mach4 \
                                device/device_request,\
                                $(user-interfaces))

Sorry for the hassle.  Once I get this and Marcus tests it, I'll also
have a clean patch for you to apply against the 2.2 tree.

Tks,
Jeff Bailey

--

-- 
 One of the great things about books is sometimes
 there are some fantastic pictures.
(Continue reading)

Roland McGrath | 24 Apr 2002 06:28
Picon

Re: ioperm

> I'm having trouble figuring out exactly what to put in this Makefile.
> There isn't a good example to follow for something that's sitting in a
> sysdeps directory.  Would I just add "ioperms" to this?:

You seem to be confused.  Just add mach_i386 after where you see mach4.
Marcus Brinkmann | 24 Apr 2002 13:39
Picon
Favicon

Re: ioperm

On Wed, Apr 24, 2002 at 12:28:31AM -0400, Roland McGrath wrote:
> > I'm having trouble figuring out exactly what to put in this Makefile.
> > There isn't a good example to follow for something that's sitting in a
> > sysdeps directory.  Would I just add "ioperms" to this?:
> 
> You seem to be confused.  Just add mach_i386 after where you see mach4.

The issue is that Jeff applied your patch (or something similar), and the
generated glibc didn't contain a trace of ioperm.

Here is Jeff's patch as he sent it to me:

diff -Nur glibc-2.2.5.old/ChangeLog glibc-2.2.5/ChangeLog
--- glibc-2.2.5.old/ChangeLog	Tue Apr 23 09:43:04 2002
+++ glibc-2.2.5/ChangeLog	Fri Apr 19 22:01:37 2002
 <at>  <at>  -1,3 +1,15  <at>  <at> 
+2002-03-17  Roland McGrath  <roland <at> frob.com>
+
+        * sysdeps/mach/hurd/i386/sys/io.h: New file.
+        * sysdeps/mach/hurd/i386/ioperm.c: New file.
+        * sysdeps/mach/hurd/i386/Dist: Add them.
+        * sysdeps/mach/hurd/i386/Versions
+        (libc: GLIBC_2.2.6): New set, add ioperm.
+        * sysdeps/mach/configure.in: New check to set HAVE_I386_IO_PERM_MODIFY.
+        (mach_interface_list): Check for mach_i386.defs.
+        * config.h.in (HAVE_I386_IO_PERM_MODIFY): #undef it.
+        * sysdeps/mach/configure: Regenerated.
+
 2002-03-31  Roland McGrath  <roland <at> frob.com>

(Continue reading)

Roland McGrath | 24 Apr 2002 19:35
Picon

Re: ioperm

Oops.  The Makefile change got committed without a change log entry by
accident, so I failed to include it in the patch.  Snarf
sysdeps/mach/hurd/i386/Makefile from the mainline.
Jeff Bailey | 24 Apr 2002 23:08

Re: gnumach release

On Wed, Apr 24, 2002 at 04:44:06AM +0200, Marcus Brinkmann wrote:

> > > The current Debian packaging of the Hurd does not meet recent Debian
> > > standards.  I can take a look at that when I'm back.

> > Marcus, can you take a look at the gnumach debian packaging and make sure
> > it's all good?

> I have fixed a small bug, except that I am happy.  We don't follow Debian
> policy to the letter, but by the time anybody cares about that policy will
> be fine again (the symlinks from /usr/doc/ to /usr/share/doc are missing,
> but they will be dropped soon anyway).

> There is really nothing holding back a gnumach release from my side.

Have we dropped gnumach-dev from this package?  From Roland's earlier
email it seems okay to introduce the one from oskit-mach.

Tks,
Jeff Bailey

--

-- 
 One of the great things about books is sometimes
 there are some fantastic pictures.
 -- George W. Bush 

Gmane