Re: Regarding meltdown/spectre

[Thomas Bushnell, BSG]

It's worth keeping in mind that there are very likely important security
bugs far more dangerous than rowhammer-style attacks in Mach, let alone the
Hurd. Security-critical applications should be pretty cautious.

On Sat, Feb 3, 2018 at 7:18 AM Samuel Thibault 
wrote:

> Hello,
>
> Jonathan Sélea, on sam. 03 févr. 2018 11:59:40 +0100, wrote:
> > How much is HURD affected by the Meltdown/Spectre bugs that has gotten
> > alot of attention lately?
>
> Just like about any OS that tries to optimize at least a bit: meltdown
> allows to read all of the main memory.
>
> There is a meltdown gnumach branch to mitigate that part, but my time
> has been caught by the need for upstreaming glibc.
>
> Samuel
>
>

Re: Canterbury Tales Prologue

[Thomas Bushnell, BSG]

Or just http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/fs.defs#n59
.



On Thu, Mar 5, 2015 at 8:14 AM A. Fleckenstein  wrote:

> On Thu, Mar 05, 2015 at 08:20:16PM +1300, Philip Charles wrote:
> > Where can I find this - I have tried.
> >
> > Phil.
>
> git clone http://git.savannah.gnu.org/cgit/hurd/hurd.git
> cd hurd/hurd
> vim fs.defs +65
>
>

Re: Canterbury Tales Prologue

[Thomas Bushnell, BSG]

Where can you find what, exactly?

On Wed, Mar 4, 2015 at 11:21 PM Philip Charles 
wrote:

> On Thu, 2015-03-05 at 04:22 +0000, Thomas Bushnell, BSG wrote:
> > It's not *quite* an excerpt.
> >
> > On Tue, Mar 3, 2015 at 5:41 AM A. Fleckenstein 
> > wrote:
> > In the hurd sources, hurd/hurd/fs.defs, line 59 begins a
> > comment, the
> > contents of which are an excerpt from the prologue of Geoffrey
> > Chaucer's
> > Canterbury Tales. Anyone know why this is?
>
> Where can I find this - I have tried.
>
> Phil.
>
>
> --
>   Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
>+64 3 488 2818Fax +64 3 488 2875Mobile 027 663 4453
>phil...@copyleft.co.nz - personal.i...@copyleft.co.nz - business
>
>
>
>

Re: Canterbury Tales Prologue

[Thomas Bushnell, BSG]

It's not *quite* an excerpt.

On Tue, Mar 3, 2015 at 5:41 AM A. Fleckenstein  wrote:

> In the hurd sources, hurd/hurd/fs.defs, line 59 begins a comment, the
> contents of which are an excerpt from the prologue of Geoffrey Chaucer's
> Canterbury Tales. Anyone know why this is?
>
> Best,
> A Fleckenstein
>
>

Re: Many questions, mostly about mach-defpager

[Thomas Bushnell, BSG]

A wired thread (vm_wire) has special vm rules inside the kernel. It's got
nothing to do with what you might expect (tying a cthread to a kernel
thread).

Thomas


On Mon, Apr 30, 2012 at 4:30 PM, Thomas Thomas  wrote:

> So, mach-defpager "wires" all of its threads. What exactly does that mean?
> I think the headers are kind-of sketchy. They do say that in GNU all
> threads
> are wired, will this apply to pthread threads, too?
>
> Nextly, it uses cthread_data to store a pointer to a thread-specific buffer
> that it uses in paging. As I see it: all threads are created when the pager
> starts up, and no threads are created afterward. Thus, I could achieve the
> same result by using a hash to map between the thread handles and the
> buffer pointers. Would this be a good idea/efficient? Mainly, I just want
> your thoughts.
>
>
> I'll leave it at this...
>
> Thomas D
>
>
>

Re: ext2fs kernel profiling: most of the time in thread management

[Thomas Bushnell, BSG]

2011/12/30 Jérémie Koenig 

> On Thu, Dec 29, 2011 at 1:25 AM, Samuel Thibault
>  wrote:
> > [...], but I believe it's still a bit revealing: I had already noticed
> > that ext2fs spends most of its time in the kernel (like 90%), and it
> > here seems we're spending a lot of time just managing the ext2fs thread
> > sleeps (no, there aren't many threads in that test, just two dozen).
>
> Could thread migration [1] maybe help with this?
>
> [1] 
> http://www.brynosaurus.com/pub/os/thread-migrate.pd
> f


One reason we didn't worry about these context switches was because
migrating threads was going to be in the mainline Mach RSN.

Thomas

Re: GNUnet News: vfork and the signal race

[Thomas Bushnell, BSG]

Oh, and in the case you describe there:

The hypervisor at start creates a global variable hypervisor_pid,
initialized from getpid().

The signal handler in the hypervisor then does this:

if getpid() == hypervisor_pid
  kill_all_children_and_exit();
else
  exit();

In this way, if the child is between fork and exec when the parent gets its
kill, and then it tries to kill the child, and the kill happens before the
child execs (the problematic case you describe), then the child simply
enters the hypervisor's signal handler, notices that it's not the
hypervisor, and exits.

Thomas


On Fri, Nov 25, 2011 at 4:09 PM, Christian Grothoff
wrote:

> On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote:
>
>> Programs which depend on the special suspend-the-parent behavior of
>> vfork were always regarded as buggy...
>>
>
> So relying on the well-documented behavior of a system call is a bug? Did
> you even read about the scenario I described at
> https://gnunet.org/vfork ? Before writing this, I looked around for
> existing information on vfork, but I didn't find anyone making a good
> argument (or even the claim) that relying on 'suspend-the-parent' was
> per-se buggy.  (Naturally, the result would be non-portable for systems
> where fork==vfork, but then maybe implementing vfork as fork is the bug?
> ;-))
>
> Happy hacking
>
> Christian
>

Re: GNUnet News: vfork and the signal race

[Thomas Bushnell, BSG]

The original BSD man page warned that the behavior should not be relied on.

Thomas
On Nov 25, 2011 4:10 PM, "Christian Grothoff" 
wrote:

> On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote:
>
>> Programs which depend on the special suspend-the-parent behavior of
>> vfork were always regarded as buggy...
>>
>
> So relying on the well-documented behavior of a system call is a bug? Did
> you even read about the scenario I described at
> https://gnunet.org/vfork ? Before writing this, I looked around for
> existing information on vfork, but I didn't find anyone making a good
> argument (or even the claim) that relying on 'suspend-the-parent' was
> per-se buggy.  (Naturally, the result would be non-portable for systems
> where fork==vfork, but then maybe implementing vfork as fork is the bug?
> ;-))
>
> Happy hacking
>
> Christian
>

Re: GNUnet News: vfork and the signal race

[Thomas Bushnell, BSG]

Programs which depend on the special suspend-the-parent behavior of vfork
were always regarded as buggy...

Thomas

On Fri, Nov 25, 2011 at 7:42 AM, Thomas Schwinge wrote:

> Hallo!
>
> On Thu, 24 Nov 2011 15:59:55 -, Planet GNU 
> wrote:
> > Many articles uniformly claim that using vfork should be
> > [avoided][1] and that the only difference between vfork and fork is (or
> > used-to-be) [performance][2] and that thus vfork is [obsolte][3]. Here, I
> > wanted to document a technical case where vfork is actually required and
> > where using vfork instead of fork (or operating system implementors
> > implementing vfork as an alias for fork) causes a hard-to-find data race.
> > [...]
> > URL: https://gnunet.org/vfork
>
> Rather ``using *fork* instead of *vfork*'', I assume?
>
>
> Just for the record, the Hurd doesn't have a vfork implementation, and
> we're thus using glibc's default POSIX vfork implementation:
>
>/* If we don't have vfork, fork is close enough.  */
>
>__pid_t
>__vfork (void)
>{
>  return __fork ();
>}
>
> I wonder how clumsy it would get to add vfork's ``parent blocks until the
> child calls _exit or exec'' functionality.
>
>
> Grüße,
>  Thomas
>

Re: mach_msg fails to copy out-of-line data when length >= 512MB

[Thomas Bushnell, BSG]

I think the fear is of resource exhaustion, but there are so many of those
problems, this would not be the first place to look IMO.

Thomas

On Thu, Sep 22, 2011 at 4:29 PM, Roland McGrath wrote:

> The whole point of OOL data is that it is relatively cheap to transfer huge
> quantities.  So I don't think there should be any arbitrary limits.
>
>
>

Re: Should diskfs_file_update be called in every io_write?

[Thomas Bushnell, BSG]

I think this could also create extra churn, by scheduling a lot of disk
writes when a series of writes are done all at once to a single file.

Traditionally, this is addressed by the every-30-seconds update task; there
is no expectation of an indefinitely postponed write.

However, much could be improved in this area. Ideally, writes would happen
at a smoothly increasing rate as page pressure increased; and ideally, the
kernel would be correctly detected sequential access patterns and paging out
finished pages speedily on its own.

Thomas

On Tue, Sep 13, 2011 at 12:50 PM, Sergio López  wrote:

> Hi,
>
> Currently, libdiskfs:io_write.c only calls "diskfs_file_update(struct
> node *np, int wait)" if the node has been opened with O_FSYNC or if
> the entire translator is operating synchronously (diskfs_synchronous
> == 1). I think calling diskfs_file_update (with wait == 0) when
> working asynchronously could help to reduce pageout pressure during
> large I/O operations (except if those operations are being generated
> by a mmap'ed file), at the expense of losing the ability of
> indefinitely delaying the actual write.
>

Re: [PATCH v2 1/4] ftpfs/host.c: use NULL (instead of 0) for pointers

[Thomas Bushnell, BSG]

I agree with Samuel. The use of NULL for pointers in C can lead people to
forget that C does not protect the types in this case.

Thomas

On Sat, Aug 20, 2011 at 9:24 AM, Samuel Thibault wrote:

> Jonathan Neuschäfer, le Mon 15 Aug 2011 22:10:06 +0200, a écrit :
> >  * ftpfs/host.c (split_server_name): assign NULL to *host, *user, and
> >*passwd instead of 0.
>
> Mmm, according to C, 0 is fine here, isn't it?
>
> Samuel
>
>

Re: set_mtime/set_atime in term/users.c, really needed?

[Thomas Bushnell, BSG]

It's what Linux does at least. And Posix likely requires it.

On Tue, Jul 26, 2011 at 4:52 PM, Samuel Thibault wrote:

> Hello,
>
> I've noticed that term/users.c calls set_atime/mtime for each and
> every io_write/read performed on a tty. This means for instance that
> each keypress on the console or via ssh will dirty the tty node and
> eventually lead to a disk write for the underlying node a few seconds
> later.
>
> Do we really need to update mtime/atime for ttys?  It seems overkill to
> me.
>
> Samuel
>
>

Re: chroot sockets (was: Introducing the hardening-wrapper package)

[Thomas Bushnell, BSG]

Cheroot isn't supposed to change the namespace of Unix domain sockets in the
case where the chroot shares a file with the main system.
On Jun 2, 2011 6:56 PM,  wrote:
> Hi,
>
> On Tue, May 31, 2011 at 09:35:32AM +0200, Samuel Thibault wrote:
>
>> You just need another partition, run debootstrap in it, and chroot
>> into it. You'll need to firmlink servers/socket/{1,2} from the root to
>> get named pipes and network sockets working.
>
> Err... What's the use of sharing the pipe server between chroot and main
> system?
>
> For the network stack, it certainly does make sense to share the server
> -- though in many situations it might be preferable to use an extra
> pfinet instance too. (With different IP address of course...)
>
> -antrik-
>
>
> --
> To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive: http://lists.debian.org/20110602021330.GA318@alien.local
>

Re: Race condition (was problem) in Mach/Hurd?

[Thomas Bushnell, BSG]

Yes. Timers do create new threads to wait for the event in question, and
then they send the signal in the normal way.
On May 10, 2011 11:18 AM, "Richard Braun"  wrote:

Re: XKB's keymaps for the Hurd console

[Thomas Bushnell, BSG]

Now you're just talking in crazy fantasy land.

On Wed, Mar 23, 2011 at 3:39 AM, Michael Banck  wrote:

> On Tue, Mar 22, 2011 at 05:06:40PM -0500, Oz wrote:
> > awsome sounds like i'll be playing some quake 3 mods in the near
> > future on the hurd.
>
> I suggest you wait for Duke Nukem Forever.
>
>
> Michael
>
>

Re: RPC to self with rendez-vous leading to duplicate port destroy

[Thomas Bushnell, BSG]

On Sun, Mar 13, 2011 at 7:25 PM, Samuel Thibault wrote:

> olafbuddenha...@gmx.net, le Mon 14 Mar 2011 03:21:43 +0100, a écrit :
> > >   There, the
> > >   rendez-vous port is thus the same as the reply port obtained above,
> > >   with the *same name*.
> > > - reauth() destroys the rendez-vous port (and thus the name!)
> > >   - a bit later, diskfs_S_io_reauthenticate has finished its work,
> > > and deallocates its rendez-vous port. But the name doesn't exist
> any
> > > more. Bad.
> >
> > I wonder, why is the rendez-vous port actually destroyed, instead of
> > just unreferencing the right?
>
> (using mach_port_deallocate instead of mach_port_destroy indeed seems
> to fix the issue, but there may be reasons for destroy rather than
> deallocate?)


mach_port_destroy : mach_port_deallocate :: exit : free

Re: RPC to self with rendez-vous leading to duplicate port destroy

[Thomas Bushnell, BSG]

I think the second call to reauth should use a second, newly-created,
rendezvous port. Why doesn't it?

Thomas
 On Mar 13, 2011 5:44 PM, "Samuel Thibault"  wrote:
> Hello,
>
> I've investigated a duplicate port destroy in ext2fs, what apparently
> happens is this:
>
> - diskfs_S_dir_lookup is called, which for some reason ends up calling
> - fshelp_fetch_root(), which calls
> - reauth(), which calls
> - mach_reply_port() to get a rendez-vous port, and then issues
> - io_reauthenticate() with that port on ext2fs itself (since it's the
> root of the system), thus triggering a call to:
> - diskfs_S_io_reauthenticate() in another thread. There, the
> rendez-vous port is thus the same as the reply port obtained above,
> with the *same name*.
> - reauth() destroys the rendez-vous port (and thus the name!)
> - a bit later, diskfs_S_io_reauthenticate has finished its work,
> and deallocates its rendez-vous port. But the name doesn't exist any
> more. Bad.
>
> How are we supposed to deal with such case?
>
> Samuel
>

Re: [bug #32693] GNU/Hurd headers don't pass c++

[Thomas Bushnell, BSG]

This is not a bug. The headers are also not usable in pascal or fortran
programs.

Thomas
On Mar 6, 2011 2:00 PM, "Samuel Thibault"  wrote:
> URL:
> 
>
> Summary: GNU/Hurd headers don't pass c++
> Project: The GNU Hurd
> Submitted by: sthibaul
> Submitted on: dim. 06 mars 2011 21:43:05 CET
> Category: None
> Severity: 3 - Normal
> Priority: 5 - Normal
> Item Group: None
> Status: None
> Privacy: Public
> Assigned to: None
> Originator Name:
> Originator Email:
> Open/Closed: Open
> Discussion Lock: Any
> Reproducibility: None
> Size (loc): None
> Planned Release: None
> Effort: 0.00
> Wiki-like text discussion box:
>
> ___
>
> Details:
>
> for instance:
> /usr/include/hurd/signal.h: In function 'hurd_sigstate*
> _hurd_self_sigstate()':
> /usr/include/hurd/signal.h:136: error: invalid conversion from 'void*' to
> 'hurd_sigstate**'
> and hurd/hurd.h
>
> Even with external "C" { }
>
> I tried to submit a patch to turn them c++, but roland rejected it,
> saying (http://sources.redhat.com/ml/libc-alpha/2007-08/msg6.html)
> “I really think you need to find another approach. The libc
> code is in C, actually in GNU C. The original purpose of C++ was
> to be usefully interoperable with C code, and it's a shame if its
> implementors have lost sight of that. But their failings are not going
> to make me start using an uglified stupid hybrid crap style instead of
> GNU C.”
>
>
>
>
>
> ___
>
> Reply to this item at:
>
> 
>
> ___
> Message posté via/par Savannah
> http://savannah.gnu.org/
>
>

Re: st_dev in struct stat

[Thomas Bushnell, BSG]

Yes, it's allowed. All names beginning with st_* are reserved if you include
the relevant header files. rdfind has no business using such names.

Thomas


On Sun, Jan 9, 2011 at 4:11 PM, Pino Toscano wrote:

> Hi,
>
> just looking at a recent build failure in Debian, "rdfind".
> There's some code like:
>
> FileInfo.hh:
>  ...
>  struct Fileinfostat {
>filesizetype st_size;//size
>unsigned long st_ino;//inode
>unsigned long st_dev;//device
>...
>  };
>
> FileInfo.cc:
>  #include "FileInfo.hh"
>  ...
>  #include 
>  ...
>  struct stat info;
>  ...
>  instance_of_struct_Fileinfostat.st_dev = info.st_dev;
>
> Such code (a simplified version of which is attached) fails to compile
> on Hurd, because in bits/stat.h there is:
>
> struct stat
>  {
>...
>__fsid_t st_fsid;   /* File system ID.  */
> #define st_dev  st_fsid
>
> Is this allowed by POSIX (most probly I'm missing the right part(s) of
> it)?
> If not, would a "fix" for the above be swapping member and define, like:
>
>__fsid_t st_dev;   /* File system ID.  */
> #define st_fsid  st_dev
>
> ?
> Thanks,
> --
> Pino Toscano
>

Re: Migration threads

[Thomas Bushnell, BSG]

The idea of migrating threads is that it happens automatically on a
synchronous rpc.

Thomas

On Sunday, December 26, 2010, Richard Braun  wrote:
> Hello.
>
> From what I understand of the Hurd history, GNU Mach is based on Mach 4.
> I read that this version was intended to include the result of research
> work made at the university of Utah, the most important being thread
> migration (for those not familiar with the concept, it means that
> threads running in client tasks "migrate" into server tasks when
> performing sync RPC). There is actually code about that in GNU Mach,
> but I'm wondering if it's actually used in the Hurd. I couldn't find
> anything related to this in the userspace servers, but the interface
> change could be light, and I might have missed them. Does anyone know if
> the Hurd servers actually use thread migration ?
>
> --
> Richard Braun
>
>

Re: ED error code

[Thomas Bushnell, BSG]

Agreed.

On Tue, Nov 2, 2010 at 7:52 AM, Michael Banck  wrote:

> On Tue, Nov 02, 2010 at 11:30:28AM +0100, Manuel Menal wrote:
> > On 02/11/2010 11:29, Samuel Thibault wrote:
> > > Manuel Menal, le Tue 02 Nov 2010 11:20:27 +0100, a écrit :
> > >>> “Macros that begin with E and a digit or E and an uppercase letter
> may
> > >>> be added to the declarations in the  header.”
> >
> > >> I'm not a native speaker, but I don't think that means E[A-Z0-9]+ are
> > >> reserved for error code macros. Only that error code macros should
> match
> > >> E[A-A0-9]+.
> >
> > > I should have quoted the start of the 7.26§ itself:
> >
> > > “7.26 Future library directions
> > > The following names are grouped under individual headers for
> > > convenience. All external names described below are reserved no matter
> > > what headers are included by the program.”
> >
> > OK, I had missed that part. I'll report bugs against those packages,
> then.
>
> I think it still makes sense to remove that ED macro if it serves no
> purpose
>
>
> Michael
>
>
>

Re: ED error code

[Thomas Bushnell, BSG]

On Sun, Oct 31, 2010 at 7:49 AM, Pino Toscano wrote:

> > Although having a reserved, generic error code macro might be
> > useful(?), `ED' is a very generic identifier. For example, clang
> > uses it in many parts of its code, which makes the build fail on
> > GNU/Hurd. I think it's likely that we'll meet this problem more than
> > once.
>
> Yes, this hit few package compilations on the Debian buildds. So far I
> collected:
>
> - boost >= 1.40:
>  - boost/math/special_functions/ellint_rd.hpp: local variable `ED'
> - gentle:
>  - enums.h: enum value `ED'
> - gpsim:
>  - src/dspic/dspic-instructions.h: class `ED'
> - httrack:
>  - src/htslib.c: `ED' used as hexadecimal number (the 0x prefix is
>prepended using a macro)
>
> Among the above, I fixed boost renaming the variable to ED_ (with a
> patch in the Debian packaging), otherwise many important packages
> couldn't have been compiled.


Please also report bugs against these packages.  As Roland points out, these
are reserved names and they shouldn't be using them.

 Thomas

Re: socket_send & socket_recv fail when sending non-socket ports

[Thomas Bushnell, BSG]

Good catch. As Roland notes the old code here has the restart race
bug. Also it was probably a leak because I think nothing here wa
counting he new make send instance the way we normally wrap all uses
of make send.

On Sunday, September 19, 2010, Manuel Menal  wrote:
> On 27/07/2010 17:39, Emilio Pozuelo Monfort wrote:
>> Hi,
>
> Hello,
>
>> While adding support for SCM_RIGHTS to glibc, I've created a testcase that 
>> sends
>> and receives some ports on the result of a socketpair() call. The ports sent
>> were initially the two ports result of another socketpair() call, and it was
>> working fine, but then I tried with the result of a couple of open() calls, 
>> and
>> socket_recv() was returning EMIGSERVERDIED.
> [snip]
>> It's returning because of this:
>>
>>         if (OutP->Head.msgh_id != 26115) {
>>                 if (OutP->Head.msgh_id == MACH_NOTIFY_SEND_ONCE)
>>                 return MIG_SERVER_DIED;
>>
>> But I'm not sure how to interpret it, and why a non-socket port in the ports
>> argument would cause this.
>> Any ideas?
>
> I think you've encountered a little bug in pflocal.
>
> Here's the story: the file descriptor you're sending is, in Mach terms,
> a send right. It gets stored by pflocal (libpipe actually) when you send
> it through socket_send() (see ). When
> you call socket_recv(), pflocal retrieves your send right and tries to
> send it to the caller. But it sends it with the MACH_MSG_TYPE_MAKE_SEND
> flag (see ). This can't work, since
> MAKE_SEND only works with receive rights. So mach_msg() fails and you
> get the error code you've mentioned.
>
> Here is a very simple fix for this bug:
>
> diff -Nurp hurd-20100829/pflocal/socket.c
> hurd-20100829.patched//pflocal/socket.c
> --- hurd-20100829/pflocal/socket.c      2010-09-19 12:49:09.0 +0200
> +++ hurd-20100829.patched//pflocal/socket.c     2010-09-19
> 12:47:23.0 +0200
> @@ -397,7 +397,7 @@ S_socket_recv (struct sock_user *user,
>      /* Setup mach ports for return.  */
>      {
>        *addr_type = MACH_MSG_TYPE_MAKE_SEND;
> -      *ports_type = MACH_MSG_TYPE_MAKE_SEND;
> +      *ports_type = MACH_MSG_TYPE_COPY_SEND;
>        if (source_addr)
>         {
>           *addr = ports_get_right (source_addr);
>
> I've tried several test cases (including yours) using your libc patch
> for sendmsg()/recvmsg() and this fix for pflocal. They all work fine.
>
> As a sidenote, this also makes us able to use sshd with
> UsePrivilegeSeparation set to yes (which used to fail because it sends
> the tty fd through sendmsg() with SCM_RIGHTS, which fails silently
> without your patch).
>
> HTH,
>
> --
> Manuel Menal
>
>

Re: sleep in microsecond or nanosecond

[Thomas Bushnell, BSG]

Right. this is why it's tricky. You don't want to force an interrupt every
microsecond just because sometimes people might be sleeping with that
granularity (because it would be too often).  But the delay is long enough
that a busy-wait is also wrong. You need to dynamically change the clock
behavior in response to the system calls.

On Mon, Aug 16, 2010 at 8:08 AM, Samuel Thibault wrote:

> Da Zheng, le Mon 16 Aug 2010 06:02:17 -0400, a écrit :
> > Should we still handle the special cases in mach_msg or in another system
> call?
> >
> > While sleeping in microseconds or nanoseconds, the kernel should do the
> loop on
> > the behalf of the user process. Why do we still need a wakeup queue?
>
> You don't want to busy-loop for whole microseconds, but rather use a
> hardware clock for that and get an interrupt when it's time to resume
> the user process.
>
> Samuel
>
>

Re: sleep in microsecond or nanosecond

[Thomas Bushnell, BSG]

Special casing is what I had in mind, but it's very tricky. The normal
wakeup-queue method is simply not adequate.

On Thu, Aug 12, 2010 at 11:42 PM,  wrote:

> Hi,
>
> On Wed, Aug 11, 2010 at 10:03:31AM -0700, Thomas Bushnell, BSG wrote:
>
> > The current technique is to use a blocking mach_msg which will never
> > complete, and with a timeout. The reason that nanosleep and usleep
> > don't work is because 10ms is the granularity of the Mach clock.
>
> Yeah, we figured that out...
>
> > Changing the interface here isn't the issue so much as changing the
> > implementation.
>
> You mean changing the way message timeouts are handled in general? Or
> special-casing the specific situation?...
>
> I think improving the timeout granularity in general would be rather
> complicated, and make little sense... I can't say anything about
> special-casing -- don't know the details of this mechanism.
>
> -antrik-
>
>

Re: sleep in microsecond or nanosecond

[Thomas Bushnell, BSG]

The current technique is to use a blocking mach_msg which will never
complete, and with a timeout. The reason that nanosleep and usleep don't
work is because 10ms is the granularity of the Mach clock.  Changing the
interface here isn't the issue so much as changing the implementation.

Thomas

On Mon, Aug 9, 2010 at 2:22 PM,  wrote:

> Hi,
>
> On Tue, Jul 06, 2010 at 08:44:30AM +0800, Da Zheng wrote:
>
> > I need a program to sleep in several microseconds, but neither
> > nanosleep() nor usleep() can work. They sleep at least 10ms. So it
> > seems the only option is to use loop and Linux kernel does so as well
> > for udelay() and ndelay(). Then I need high resolution timing. I think
> > I can use TSC, but it's better to be system independent. There is
> > clock_gettime() in POSIX, but surprisingly it's not implemented in
> > glibc in Hurd. Any suggestions?
>
> For the record: I still think that the best solution would be a special
> kernel call that does precise delays; automatically using delay loops
> for short sleeps, or the best available timer for longer ones. This
> stuff is pretty machine-specific, and thus -- at least in the Mach world
> -- it's a job for the kernel. (Though even L4 does timer handling in the
> kernel AIUI -- after all, the kernel needs some timer support itself, to
> implement process scheduling...)
>
> Of course such a kernel call would still be a bit rough for really short
> delays, because of the general kernel call overhead. I guess it would be
> good enough for most applications though.
>
> -antrik-
>
>

Re: RPC user stub libraries (was: error compiling hurd after gnumach interface change)

[Thomas Bushnell, BSG]

>   * What's the reason for having a libmachuser / libhurduser be part of
>glibc?
>
>Is it for Roland's convenience, or is there a technical reason?  Can
>we move it out of the glibc build process?
>

Given the need for the libraries, they have to be built somewhere. Since
glibc needs to use these interfaces, you can't possibly have gnulibc without
them.


>  * What's the reason for having a libmachuser / libhurduser at all?
>

See above.

   Actually, if I understood correctly, in his Viengoos kernel, Neal
>is doing all RPC stub code generation in the pre-processor, thus
>has it as inline code at every call site.  This has one immediate
>advantage: GCC can optimize it, as there is no function-call
>boundary.  Should we be doing the same?  Someone should do some
>measurements.  Neal, any off-hand comments?
>

That's fine, but it doesn't matter: you still need the function to exist, so
that people can take the address of it.

What Karim should do is specify a prefix (there are facilities for just
this) which will then get added to each RPC name so it doesn't conflict with
the standard version.

Thomas

Re: Berkeley Packet Filter

[Thomas Bushnell BSG]

On Mon, 2009-07-06 at 21:01 +0800, Da Zheng wrote:
> Samuel Thibault wrote:
> > Da Zheng, le Mon 06 Jul 2009 14:23:20 +0800, a écrit :
> >   
> >> Thomas Schwinge wrote:
> >> 
> >>> Zheng Da asked me to tell him about previous work that has been done on
> >>> supporting and using Berkeley Packet Filters.  Here it is:
> >>> 
> >>>   
> >> GNU Savannah bug #25054 -- Kernel panic with eth-multiplexer, reported 
> >> by antrik, isn't a bug in gnumach.
> >> It was caused by a bug in eth-multiplexer and the bug has been fixed.
> >> Maybe you can remove it in the page.
> >> 
> >
> > E, a bug in a userland tool is not supposed to cause a kernel panic,
> > so there is a bug in the kernel too.
> >   
> What should the kernel do if it is out of resources?

Cause the system call to return an error, at the very least.

But the old rule in Mach was that the system can't cope with a loss of
resources, and until that's fixed, a panic is better.

Re: Weird O_RDWR flag definition

[Thomas Bushnell BSG]

On Fri, 2008-10-31 at 23:56 +0100, Adam Tkac wrote:
> 
> if (mode & O_WRONLY)
>   die();

That was never correct code.

Thomas

Re: What operations in store_parsed_open() need the privilege?

[Thomas Bushnell BSG]

On Thu, 2008-08-28 at 23:48 +0200, Da Zheng wrote:
> If the non-user can access /dev/hda1, it means he can operate the hda1 
> device directly without the help of the file system.
> Is the user really allowed to do it? In Linux or other Unix, this kind 
> of operation is forbidden, I think.

It depends on the permissions on the device node; that's the whole
point.

Thomas

Re: What operations in store_parsed_open() need the privilege?

[Thomas Bushnell BSG]

On Thu, 2008-08-28 at 08:42 +0200, Neal H. Walfield wrote:
> At Wed, 27 Aug 2008 15:05:59 -0700,
> Thomas Bushnell BSG wrote:
> > 
> > On Wed, 2008-08-27 at 23:32 +0200, Da Zheng wrote:
> > > I know boot fails and gets EPERM when it calls store_parsed_open, but I 
> > > need to know what operations inside store_parsed_open() fail. Otherwise, 
> > > I don't know how to fix it.
> > 
> > Boot assumes that it is run as root, and assumes that quite thoroughly.
> > You need to have boot simply not even *try* to open such a device.
> 
> I don't understand why boot should somehow override the user in this
> regard.  It is perfectly legitimate, I think, to give a non-root user
> access to, e.g., /dev/hda1.  In that case, why should boot not even
> try to open the device?

Yes, I think of course you're right.

Thomas

Re: What operations in store_parsed_open() need the privilege?

[Thomas Bushnell BSG]

On Thu, 2008-08-28 at 00:21 +0200, Da Zheng wrote:
> Thomas Bushnell BSG wrote:
> > On Wed, 2008-08-27 at 23:32 +0200, Da Zheng wrote:
> >   
> >> I know boot fails and gets EPERM when it calls store_parsed_open, but I 
> >> need to know what operations inside store_parsed_open() fail. Otherwise, 
> >> I don't know how to fix it.
> >> 
> >
> > Boot assumes that it is run as root, and assumes that quite thoroughly.
> >   
> It's exactly my task, to make every user able to run their own subhurd.

Right.  You'll have to do more than fix up your servers to deal with the
non-root situation (as you know, proc will require careful work).  But
also boot will require significant work.

> > You need to have boot simply not even *try* to open such a device.  Note
> > that boot isn't calling your servers at all.  It calls the ones of its
> > containing environment.
> >
> > I assume that store_parsed_open fails because it doesn't have
> > permissions on the underlying /dev node.
> >   
> yes. but to be specific, it really depends on how we run boot.
> If we run "boot -T device servers.boot hd1", what store_parsed_open does 
> is to open the device by calling get_privileged_ports() and device_open().
> In this case, there is nothing to do with /dev nodes, and my proc proxy 
> might be able to give a help:-)

The question you must think carefully about is which functions are
called by boot, and thus run in the context of the parent Hurd.  

Thomas

Re: What operations in store_parsed_open() need the privilege?

[Thomas Bushnell BSG]

On Wed, 2008-08-27 at 23:32 +0200, Da Zheng wrote:
> I know boot fails and gets EPERM when it calls store_parsed_open, but I 
> need to know what operations inside store_parsed_open() fail. Otherwise, 
> I don't know how to fix it.

Boot assumes that it is run as root, and assumes that quite thoroughly.
You need to have boot simply not even *try* to open such a device.  Note
that boot isn't calling your servers at all.  It calls the ones of its
containing environment.

I assume that store_parsed_open fails because it doesn't have
permissions on the underlying /dev node.

Thomas

Re: What operations in store_parsed_open() need the privilege?

[Thomas Bushnell BSG]

On Wed, 2008-08-27 at 03:48 +0200, Da Zheng wrote:
> > It sounds as if you got EPERM from store_parse_open, but
> > proc_getprivports is not being called, so you are having trouble
> > understanding why you got an error message at all.
> >   
> Yes, exactly.
> > This will depend much on what the store specification was which was
> > passed to store_parse_open.  Can you provide more details?
> >   
> I run subhurd with "boot servers.boot /dev/hd1", so the libstore should 
> read the disk.

I believe it fails inside boot's main() function when boot attempts a
store_parsed_open on /dev/hd1.  Why would you expect your proc server to
have anything to do with that?

Thomas

Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Wed, 2008-08-27 at 03:38 +0200, Da Zheng wrote:
> Thomas Bushnell BSG wrote:
> > On Wed, 2008-08-27 at 01:56 +0200, Da Zheng wrote:
> >   
> >>> Yes, but the point here is that *you* are opening that file and
> >>> expecting something to happen.  I thought you were writing the program
> >>> which would *serve* that file.
> >>>   
> >>>   
> >> I know it's a bit confusing. Then what should I do?
> >> 
> >
> > If you want to serve that file, you'll be writing a trivfs translator
> > for it. 
> >   
> I'm sorry, I don't understand you.
> The translator associated to the device file is actually written with 
> libtrivfs.

Good grief, I can't keep track of what you are talking about.

I'm just about to give up, but I'm going to try.  You omit a lot of
information.  I'm going to ask you to stop doing that.  If you want
communication to succeed, you MUST try and give all the information, and
not just guess that I can guess what's in your head.  I can't.

Ok, so I saw code that opened these /dev/eth0 nodes.  I saw no code that
implements them.  I said, "hey, what implements them?" and you said,
"well, this is what they will do."  Ok, I'll try again.  What implements
these /dev/eth0 nodes?  Is that something you've written?  Something
that already exists? 

> Do you mean I should implement the IO operation? so other programs can 
> read and write the device file to communicate with the kernel device?
> but what we want is a translator that helps other programs get the port 
> to the device. That's it.

Um, that is *obviously* not what you are wanting.  (And please, don't
say "what we want"; just say "what I'm trying to implement".  I can
hardly keep track of what you are working on because it seems to change
from message to message.)

If you only wanted "the port to the device", it would be a simple
translator that held the device master port and handed out the Mach
device port.

Obviously you do NOT want simply to "help other programs get the port to
the device."  Please help me understand.  What *exactly* is your
project?

Thomas

Re: What operations in store_parsed_open() need the privilege?

[Thomas Bushnell BSG]

On Wed, 2008-08-27 at 01:57 +0200, Da Zheng wrote:
> I'm trying to make subhurd work without root's permission, so the first 
> task for me is to find the operations need the privilege.

That's a worthy task.

> I have a problem in store_parsed_open().
> I believe store_parse_open() calls dev_open() if the filesystem of 
> subhurd is in a disk.
> The first privilege operation I can find is get_privileged_port() when I 
> look into the code of libstore.

That's right.  To make your project succeed, you'll need to implement a
device master port far more fully than the existing subhurd boot does.

> I wrote a proc proxy, so I can track what RPC routines in process.defs 
> are called (but the main purpose of the proc proxy is to give a program 
> the master device port).
> When I tried to run the subhurd with the normal user, I got the 
> "Permission denied" error when store_parse_open() is called but I didn't 
> see proc_getprivports() was called in the proc proxy.
> I wonder where is the privilege operation?

I'm having trouble understanding exactly what you were expecting or
where this error was coming from.

It sounds as if you got EPERM from store_parse_open, but
proc_getprivports is not being called, so you are having trouble
understanding why you got an error message at all.

This will depend much on what the store specification was which was
passed to store_parse_open.  Can you provide more details?

Thomas

Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Wed, 2008-08-27 at 01:56 +0200, Da Zheng wrote:
> > Yes, but the point here is that *you* are opening that file and
> > expecting something to happen.  I thought you were writing the program
> > which would *serve* that file.
> >   
> I know it's a bit confusing. Then what should I do?

If you want to serve that file, you'll be writing a trivfs translator
for it. 

Thomas

Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Tue, 2008-08-26 at 13:09 +0200, Da Zheng wrote:
> The purpose of the translator is to help other programs get the port to 
> the device, so I suggested if it was OK that file_name_lookup() returns 
> the port to the device directly.
> antrik said it was quite confusing for him because file_name_lookup() 
> should return a Hurd port, not a Mach port.
> Here are his suggestions. You can see them in the message:
> http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg5.html
> Few people gives suggestions, So antrik said I could use any design he 
> suggested.

Yes, but the point here is that *you* are opening that file and
expecting something to happen.  I thought you were writing the program
which would *serve* that file.

Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Mon, 2008-08-25 at 19:31 +0200, Da Zheng wrote:
> I don't want to destroy the port. I just want to check if all ports have 
> already been destroyed before the goaway routine is called.

To check, you use the counting routines provided.

> The device file is created by a translator to help other user programs 
> to open the device.
> For example, we can create a device file /dev/eth0 with the translator. 
> When the user program calls file_name_lookup() on the file and 
> device_open() as I do in the code, I actually open the device of eth0.
> So device_file here can be /dev/eth0, /dev/eth1, etc.

You are opening that file as if you expect it to be there, and to return
you a port you can do device_open on.  That seems very confused to me.
You call device_open on master device files.  

Thomas

Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Mon, 2008-08-25 at 13:20 +0200, Da Zheng wrote:
> Yes, these ports have the receive rights.
> They are used for the user program, and I want to make sure they have 
> all been destroyed before the translator exits, so the translator knows 
> all user programs connected to it have all exited and it can exit 
> without causing any problems.
> I think every translator does it. For example, pfinet checks 
> "ports_count_class (socketport_class) != 0" in its trivfs_goaway(). If 
> the count of socket port class isn't 0, pfinet doesn't exit.

If you are exiting in the goaway routine, this is the right thing,
because the goaway routine is really about detaching from the parent
filesystem, and then exiting only once your users are done.

pfinet is not destroying any ports here, which is quite different from
what you asked.  If you want to make sure there are no ports, the thing
pfinet does is right.  If you want to destroy ports unconditionally,
then exit, then you can just exit.  That will automatically deallocate
all the ports in the task, including its receive rights.

> Right, I define three structures. My translator still run in one thread, 
> so I don't define a lock. and it's very uncommon for the device to exit 
> before the user program exits, so I don't destroy the port for the user 
> when the port for the device is destroyed. Actually the user program 
> will find it anyway.
> 
> struct proxy_user
> {
>   struct port_info pi;
>   struct proxy *proxy;
> };
> 
> struct proxy_device
> {
>   struct port_info pi;
>   struct proxy *proxy;
> };

Note that if you don't have any difference between these structures--if
there is nothing extra you need--you can combine them into one name.
Port classes will keep them separate for practical purposes.

> struct proxy
> {
>   struct proxy_device *device;
>   mach_port_t deliver_port;
>   hurd_ihash_locp_t p_deliverport_hashloc;
>   mach_port_t device_port;
> };


> 
> To create the proxy_user and proxy_device objects:
> 
> error_t
> create_proxy_user (struct proxy *proxy, mach_port_t *port)
> {
>   error_t err;
>   struct proxy_user *user;
> 
>   err = ports_create_port (user_portclass, port_bucket, sizeof (*user), 
> &user);
>   if (err)
>   return err;
>   user->proxy = proxy;
> 
>   *port = ports_get_right (user);
>   ports_port_deref (user);
>   return 0;
> }

Just to repeat here, b/c there was confusion before.  The
ports_port_deref you call here has nothing to do with the
ports_get_right call.  Nothing at all.  It is there because of the
ports_create_port call.

> Here are the most important server side functions in device.defs.
> In ds_device_open(), I create the proxy_user and proxy object.
> 
> kern_return_t
> ds_device_open (mach_port_t master_port, mach_port_t reply_port,
> mach_msg_type_name_t reply_portPoly,
> dev_mode_t mode, dev_name_t name, mach_port_t *device,
> mach_msg_type_name_t *devicetype)
> {
>   kern_return_t err;
>   mach_port_t master_device;
>   mach_port_t user_port;
>   struct proxy *proxy;
> 
>   if (device_file == NULL)
> return D_NO_SUCH_DEVICE;
> 
>   master_device = file_name_lookup (device_file, 0, 0);
>   if (master_device == MACH_PORT_NULL)
> return errno;
> 
>   proxy = (struct proxy *)calloc (1, sizeof (*proxy));
>   if (proxy == NULL)
> {
>   mach_port_deallocate (mach_task_self (), master_device);
>   return D_NO_MEMORY;
> }
> 
>   err = device_open (master_device, mode, name, &proxy->device_port);
>   mach_port_deallocate (mach_task_self (), master_device);
>   if (err != KERN_SUCCESS)
> {
>   free (proxy);
>   return err;
> }
> 
>   err = create_proxy_user (proxy, &user_port);
>   if (err)
> {
>   mach_port_deallocate (mach_task_self (), master_device);
>   free (proxy);
>   return err;
> }
> 
>   *device = user_port;
>   *devicetype = MACH_MSG_TYPE_MAKE_SEND;
> 
>   return 0;
> }

What is device_file set to?

Note that network device users are not obliged to use device_set_filter!
They can just use device_read and device_write as normal if they please.
You'll need to implement the whole device interface.

> Since eth-filter works as a proxy for several user programs, it can 
> receive many device_open requests.
> Should I call device_open only once in eth-filter or call it as long as 
> a device_open request comes?
> eth-filter connects to only one device, so device_open always returns 
> the same send right, even though the mode of opening device is changed.
> I don't know if it will cause a problem.

I would just open it once, with maximal permissions, and then manage the
permissions yourself.

Thomas

Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Sun, 2008-08-24 at 19:36 +0200, Da Zheng wrote:
> As I said above, I have to make sure all ports created for the user 
> program have been destroyed before the translator exits.

Are these ports that the translator has the receive rights to?  If so,
then when the translator exits, they will all be destroyed.  

> Assume that I create a port for the user programs and give its send 
> right to them.
> After ports_create_port() and several ports_get_right() are called, the 
> reference count of the port is 2.

Yes.

> When all user programs exit, the no-senders notification for the port is 
> generated.
> If ports_port_deref() isn't called somewhere, the reference count of the 
> port is still 2 when the no-senders notification comes, therefore, the 
> port cannot be destroyed by ports_no_senders() or 
> ports_do_mach_notify_no_senders() or something else.

Exactly.  That's because when you call ports_create_port, you create a
reference, and you must free it before that stack frame returns.

> That's why I ask you for a suggestion where I should call 
> ports_port_deref() to decrease the reference count when there is a 
> sequence of ports_get_right() calls.

I'm keep telling you.  Calling ports_get_right does not mean you need to
call ports_port_deref, and never does in normal Hurd code.  But calling
ports_create_port does create a reference, and *that* reference must
indeed be freed, by ports_port_deref, before the calling routine is
done.

Now, this has *NOTHING* to do with calling ports_destroy_right, which is
only needed in very special cases.

> It's exactly what I did after I followed your suggestion to use the 
> structure of proxy_user, proxy_device and proxy:-).
> In the clean routine of proxy_user, I also freed the memory of proxy.
> In the clean routine of proxy_device, I just set the pointer to the 
> proxy_device in the proxy structure null (device->proxy->device = NULL).

But as you point out, the Mach device still has a reference to your
port, so you do need to destroy the right.  This is really because you
are using libports to serve a port which is not following normal Hurd
protocols.  (The port a Mach device sends filtered packets on is not
following Hurd protocols.)

Once you have things in a way you think looks good, why don't you post
the relevant code here, so that more eyes can look at it?

Thomas

Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Sat, 2008-08-23 at 09:36 -0700, Thomas Bushnell BSG wrote:
> So you have two ports.  When the one going to the user is destroyed, you
> need to tell the device not to send any more packets.
> 
> And we have a way to do that: by calling device_set_filter, and clearing
> out the port there.  The driver will then drop its send right for you.

Ah, I see now, the device_set_filter interface is very unusual.  I had
remembered that you could have only one filter at a time, but that's not
correct.  The only way to make the filter go away is to make the port go
dead.

So this is, as it happens, a rare case where you do need
ports_delete_right.

I still insist that the correct structuring of the structs is as I
outlined.

First, you still want the memory be allocated in the way that libports
expects:

struct filter_user {
  struct port_info pi;
  struct filter_setup *filter;
};

struct filter_device {
  struct port_info pi;
  struct filter_setup *filter;
};

struct filter_user and filter_device need to be distinct port classes.
They might end up being the same struct if you don't need any extra
members, of course.

struct filter_setup {
  struct mutex lock;
  struct filter_user *u; /* does NOT hold a reference */
  struct filter_device *d; /* does NOT hold a reference */
  ...
};

In the clean routine for filter_user, you would need to do the
following:
  if (fu->filter->d)
ports_destroy_right (fu->filter->d);
  fu->filter->d = 0;

The ports_destroy_right will nuke the receive right, causing the kernel
to (eventually) clean up its data structures, and the ports_port_deref
accounts for the FU->dev reference itself which is going away.

You have to be very careful to remember that you have no control over
the order the clean routines would be called and so forth.

Thomas

Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Sat, 2008-08-23 at 13:25 +0200, Da Zheng wrote:
> I have to make sure every ports has been destroyed so when the 
> translator exits, it can check if there are still users.

Huh?  When the translator exits, all the ports are going to be destroyed
anyway.

> OK, maybe I should make the things more clear.
> I'm writing a filter translator called eth-filter whose function is to 
> forward and filter the packet between the network device and the user 
> program such as pfinet,
> so eth-filter needs to build a "pipe" for them.
> eth-filter needs two ports, so it can get the packet from the user 
> program and the network device.

That's the task.

> The user program can exit, it's quite normal, but the device cannot.
> so the network device always holds the send right to the port of 
> eth-filter.

Yes, fine.

> Let's see what the result will be. The device keeps sending the packet 
> to the eth-filter and eth-filter should forward it to the user program.
> But the user program doesn't exit any more.

> In this case, eth-filter must tell the device: the user program doesn't 
> exist, so please don't send me any packets that is to the user program.

Excellent.  *That's* the right way to think.

So you have two ports.  When the one going to the user is destroyed, you
need to tell the device not to send any more packets.

And we have a way to do that: by calling device_set_filter, and clearing
out the port there.  The driver will then drop its send right for you.

> The only way I can find is to destroy the port for the device. I think 
> it's the way of operating the network device. device_close() doesn't work.
> After the port is destroyed, the device will find the send right is a 
> dead name and stop sending the packets (that should be to the user 
> program) to eth-filter.

The reason device_close doesn't work is because the device_t is totally
separate from the port installed with device_set_filter. 

> It's exactly why I think it's difficult to operate.
> ports_get_right() can be called several times. Let's think about the 
> sequence as follow (it's not in the same function):
> struct port_info *port;
> ports_create_port(..., &port);
> ...
> ports_get_right(port);
> ...
> ports_get_right(port);
> ...
> ports_get_right(port);
> ...
> When should I call ports_port_deref()? after the first time of calling 
> ports_get_right()? or after the last time?

You don't call ports_port_deref because of ports_get_right *AT ALL*.
You call it because the variable PORT holds a reference, and *that*
reference is going away.  The call to ports_port_deref has *nothing* to
do with ports_get_right at all.  It is because the variable PORT holds a
reference, and that's a stack variable which is going to be deallocated
once this function returns.

Thomas

Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Fri, 2008-08-22 at 02:54 +0200, zhengda wrote:
> When a port_info object is created by ports_create_port() and 
> ports_get_right() hasn't been called,
> we have to call ports_port_deref() to destroy the port_info object.

You are still organizing things wrongly, and that's what's messing you
up.  You should basically *never* be thinking "how will I destroy the
port_info object?"  That you are thinking this is already a symptom of
the difficulty.  It is your *setup* that is wrong.

struct foo {
  struct port_info *a, *b;
  other_stuff;
}; 

is WRONG.  It will remain wrong, no matter how many times you want it to
work.  What you want is:

struct foo {
  other_stuff;
};

struct foo_a {
  struct port_info pi;
  struct foo *foo;
  ...
};

struct foo_b {
  struct port_info pi;
  struct foo *foo;
  ...
};

I've now said this twice.

ports_port_deref is not "the way to destroy a port_info object"; rather, it 
deletes a reference to it.
When all references go away, of course, the object is automatically destroyed.

ports_port_destroy is not "the way to destroy a port_info object";
rather, it is the way to destroy a receive right in the very unusual
case that some external sort of thing has required its destruction.
It's hard for me to even think of a case where it's the right thing, it
is so rare.

There is no function which is "the way to destroy a port_info object".
This is intentional, and if you use the interface properly, you won't
need one.

> struct port_info *foo;
> ports_create_port(portclass, bucket, sizeof(*foo), &foo);
> 
> ports_port_deref(foo);  // ports_port_destroy(foo) doesn't work here.

It works just fine, *if your intention is to delete the receive right*--
a rare and unusual thing.

> When a port_info object is created and ports_get_right() is called,
> struct port_info *foo;
> mach_port_t port;
> ports_create_port(portclass, bucket, sizeof(*foo), &foo);
> port=ports_get_right(foo);
> In this case, there are two ways to destroy the port_info object:
> either to call ports_port_deref() and then ports_destroy_right() explicitly,
> or to call ports_port_deref() and then wait until no_senders 
> notification is generated.

NO, NO, NO.  The reference count is poor-man's-gc.  It's garbage
collection.  You are responsible for maintaining the reference count,
and letting the object be destroyed *on it's own*.  

EVERY live pointer to the object must be accounted as a reference.  Note
how badly your scheme works:

struct foo {
  port_info *a, *b;
};

If you write that, then every struct foo *MUST* hold a reference to the
A and the B.  And, as a result, they will never get gc'd, because you
will never see the references go to zero.

> One end of the pipe is the user program and the other is the device, so 
> I need to create two port_info objects for the pipe.

Yes, this is correct.

> When the user program exits, the port for it can be destroyed by 
> no-sender notification,

You are thinking "how can we destroy the port", which is the wrong
question.  But yes, when the user has had this event, the port can be
destroyed.

> and meanwhile, the other port should also be destroyed, 

WHY?  What possible value is there in destroying the other port?

Notice, for example, the way pipes work.  Suppose the reader dies, and
there are no readers.  We do not destroy the writer's port.  Heaven's
no!  Instead, we accept requests on it, just as normal, *and we return
EPIPE*.

We don't need to destroy the port, nor should we.  It still has users.
Yes, their requests may fail, but that doesn't mean there aren't still
people holding send rights who are entitled to see the protocol
continue.

> If the port for the device isn't destroy with ports_destroy_right(), it 
> might never be destroyed
> because its send right might always be kept by the device, and 
> no-senders notification will never be generated.

I'm confused.  How does a device hold send rights to your port?  Mach devices 
don't work that way.  What is this "device" that is holding a send right?

> 
> Another thing surprises me is that in some code of hurd, 
> ports_port_deref() is used with ports_get_right() together. For example,
> error_t
> S_io_duplicate (struct sock_user *user,
> mach_port_t *newobject,
> mach_msg_type_name_t *newobject_type)
> {
>   struct sock_user *newuser;
>   if (!user)
> return EOPNOTSUPP;
> 
>   __mutex_lock (&global_lock);
>   newuser = make_sock_user (user->sock, user->isroot, 0, 0);
>   *newobject = ports_get_right (newuser);
>   *newobject_type = MACH_MSG_TYPE_MAKE_SEND;
>   ports_port_deref (newuser);
>   __mutex_unlock (&global_lock);
>   return 0;
> }

When we create the port_info, it has one reference, held by the variable
NEWUSER.  Then we call ports_get_right and create a send right.  Now
there are two references, one held by NEWUSER, and one held by the
outstanding send rights.  Then we release the references held by
NEWUSER, and return.

At the end of the function, the reference count i

Re: [PATCH] libfshelp: keep stdin and stdout open

[Thomas Bushnell BSG]

On Fri, 2008-08-22 at 01:49 +0200, [EMAIL PROTECTED] wrote:
> Hi,
> 
> On Tue, Aug 19, 2008 at 11:29:28PM -0700, Thomas Bushnell BSG wrote:
> > On Fri, 2008-08-01 at 21:18 +0100, Samuel Thibault wrote:
> 
> > > I'd agree on the principle to not leave a nul port for stdin/stdout,
> > > any other opinion on this?
> > 
> > I disagree.  Translators don't have such ports, and making them null
> > encourages programs to write on them, possibly expecting that the output
> > will go somewhere.
> 
> Well, I'm not sure I entirely understand what is being discussed here;
> so pardon me if this is a stupid notion: Is there some fundamental
> reason why (active) translators couldn't actually get real stdin/stdout
> from the settrans?...

Active translators certainly do get real stdin/stdout ports when created
with settrans -a.  It's when they are started up from passive
translators that there is a difficulty.  What would you like those
stdin/stdout to be connected to?

Thomas

Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Thu, 2008-08-21 at 11:26 +0200, zhengda wrote:
> In eth-filter, I define a structure
> struct proxy_info
> {
>   /* For receiving packets from pfinet. */
>   struct port_info *pfinet_pi;
>   hurd_ihash_locp_t p_pfinetpi_hashloc;
> 
>   /* For receiving packets from the network interface. */
>   struct port_info *device_pi;
>   hurd_ihash_locp_t p_devicepi_hashloc;
> 
>   /* For delivering packet to pfinet. */
>   mach_port_t deliver_port;
>   hurd_ihash_locp_t p_deliverport_hashloc;
> 
>   /* The port to the network interface. */
>   mach_port_t device_port;
> };
> Because I cannot put two port_info objects in one structure, I put their 
> pointers in the structure.

Ah, there's the mistake.  First, "struct proxy" is fine; no need for
"info".  You have a situation very much like a pipe, except that you are
doing network packet stuff on each port instead of read/write on each
port.

So take a look at what pflocal does for a hint.

You want something like

struct proxy_user
{
  struct port_info pi;
  struct proxy *px;
};

struct proxy
{
  int refs;
  struct mutex lock;

  a queue;
  other stuff maybe;
};

> The result is that I cannot find the proxy_info structure with 
> ports_lookup_port(). I define some hash tables for it and do exactly as 
> what ports_lookup_port() does. That's why I need to get the name of the 
> port.

Here you are totally violating the abstraction of libports.  Instead,
you want a single structure for each outstanding port--just like
libports wants--and then that structure points to the common structure
for what they share.

The whole point of libports is to *eliminate* the need for that.  Simply
turn your pointers around and have them point the other way (as I sketch
above) and your life will be much easier.

> ports_destroy_right decrease the reference count for the port only when 
> the port has the send right (PORT_HAS_SENDRIGHTS flag). When the port 
> gets the send right, its reference count is always increased by 1. so as 
> long as the functions in libports are used correctly, 
> ports_destroy_right() cannot destroy the port_info structure.
> As I understand, in order to destroy a port created by 
> ports_create_port(), we have to call ports_destroy_right() and 
> ports_port_deref().

Notice that Hurd servers basically never think "oh, I want to destroy a
port."  That's a very unusual thing.  You don't keep track of that; this
is exactly what libports is for.

Your interpretation of ports_destroy_right is wrong.  It does always
destroy the port, completely.

The mach_port_mod_refs is what destroys the port.  Note that *all* the
outstanding send rights, however many there may be, occupy only *one*
reference in PI->refcnt.  So when we do a ports_destroy_right, first we
blow away the receive right, which causes the kernel to nuke all the
outstanding send rights and turn them into MACH_PORT_NULL.  Then we
account for their loss by doing a ports_port_deref, if there were any
send rights.  (Notice that the no-senders notification we have
outstanding is going to be cancelled when we nuke the receive right.)

The only reason that ports_port_deref might not immediately eliminate
the port is because there are likely *other* references to the port,
perhaps in some other thread.  We can't actually free the structure
until they are done with it.  But trule, ports_destroy_right does blow
the whole thing away.

> >> For the second case, if notify is null, how can we receive the 
> >> notification? The same question for the dead-name notification (the 
> >> argument notify is also allowed to be null).
> >> 
> >
> > You can't.  The result is that you are cancelling the notification if
> > one is outstanding.
> >   
> The mach manual doesn't tell that:(, or I understand it in a wrong way.

What was your understanding of it?

Thomas

Re: Some questions about libports and notification of ports

[Thomas Bushnell BSG]

On Wed, 2008-08-20 at 22:47 +0200, zhengda wrote:
> I want to get the confirmation from you about the usage of 
> ports_get_right(), ports_destroy_right() and ports_port_deref().
> When I use ports_get_right() to get the receive right of the port, I 
> should always make a send right for the port. So if we just want to get 
> the name of the port, we should use the port_right field in port_info 
> directly. Am I right?

The "normal" call is ports_get_send_right.  You should think of
ports_get_right as simply ports_get_send_right where you are responsible
for a MACH_MSG_TYPE_COPY_SEND invocation to come.  The only reason for
ports_get_right is to avoid the system call inside of
ports_get_send_right in the usual case.

That means that it is *not* a good idea to think of ports_get_right as
returning you the name of the receive right.  Notice that it increments
a reference count!

So the question you are asking then is "how can I get the name of the
receive right for a port if I am using libports?"  And the answer is:

1) Why do you think you need the receive right?
2) Don't.

Such an operation breaks the abstraction of the ports library.  You
should pretty much not be dereferencing *anything* inside a struct
port_info.

> ports_destroy_right() is only used to destroy the receive right and it 
> shouldn't be able to destroy the port_info object. ports_port_deref() is 
> the one to destroy the port_info object (of course, only when its 
> reference count is 0), right?

Yes, but note that destroying the receive right is quickly going to
result in the reference count for the port going to zero, and the
consequent destruction of the port_info structure.  But that step will
happen later, when the last no-senders notification comes in.

> I realize now that I really need to use libports very carefully.

Well, basically, use it the right way.  Conform your thinking to *its*
way of thinking. :)  Then it's easy.

> Another question is about the notification of no senders.
>  From the mach manual, I see there are two situations where no-senders 
> notification is generated.
> 1. "If notify is not null, and the receive right’s make-send count is 
> greater than or equal to the sync value, and it has no extant send 
> rights, than an immediate no-senders notification is generated."
> 2. "Otherwise the notification is generated when the receive right next 
> loses its last extant send right."
> For the first case, why is the notification generated only when 
> make-send count >= the sync value? Is there any special reason for this?

Yes.  They are thinking of a case where you might want to create a port,
and schedule a no-senders notification, and *then* start creating the
send rights.  The sync value says that no-senders only counts *after*
you've created the send rights you wanted to make.

Notice that ports_get_right works in exactly this way.  If we are making
a send right for the first time, we ask for a notification, and specify
the sync value so that we don't generate an immediate notification.

> For the second case, if notify is null, how can we receive the 
> notification? The same question for the dead-name notification (the 
> argument notify is also allowed to be null).

You can't.  The result is that you are cancelling the notification if
one is outstanding.

Thomas

Re: dir_lookup, locking and EINTR

[Thomas Bushnell BSG]

On Thu, 2008-08-21 at 00:39 +0100, Samuel Thibault wrote:
> That's safer indeed.  To make things simpler, the patch below just
> systematically resets NEWPI and NEWPO to NULL as soon as they don't need
> to be dereferenced, does it look ok?

It does, but "NULL" is entirely unnecessary.  I much prefer setting
pointer variables to "0", which is the way the vast majority of the Hurd
code is written. :)

Thomas

Re: procfs - Design Issue

[Thomas Bushnell BSG]

On Tue, 2008-06-17 at 00:18 +0100, Samuel Thibault wrote:
> Hello,
> 
> Madhusudan C.S, le Tue 17 Jun 2008 04:12:42 +0530, a écrit :
> > 1.   Is it better to free all those nodes as soon as they are displayed and
> > create them whenever they are required?
> 
> Just do that. No need to cache anything. Just let the reference counting
> free the node when the client doesn't need it any more. A lot more
> simple and should be just enough.

And return a sane error in the case a user tries to operate on a node
which for a process which has exited.  "Sane error" of course means
"more or less whatever BSD and/or Linux do".

Thomas

Re: Possible bug in name of command 'settrans'

[Thomas Bushnell BSG]

On Tue, 2008-06-10 at 12:59 +0400, A.Salatov wrote:
> No, you correct me if I'm wrong, but when I think about 'settrans' my
> mind always going to compare it to 'umount' and I started to think about
> a reasons why 'umount' is 'umount' and not 'unmount'. The simplest
> reason for it, that I could imagine, it is so because it less typing to
> do. You ever try to type 'setrans' instead 'settrans'. If it is not
> enough, may be it is beter to have even shorter form, like - 'strans' :)
> In this case 's' would actualy stand for "SetTRANSlator", and it OK? Ok,
> all this topic is a kinda joke, but with an sense in it as I supose. If
> no one would treat it in real, well then it is complitly a joke. :(

It's settrans because it's "set trans".  

If you want an explanation for "umount", then you're going to start
wanting one for "creat".  

Thomas

Re: [PATCH] libfshelp: keep stdin and stdout open

[Thomas Bushnell BSG]

On Fri, 2008-08-01 at 21:18 +0100, Samuel Thibault wrote:
> Hello,
> 
> I'd agree on the principle to not leave a nul port for stdin/stdout,
> any other opinion on this?

I disagree.  Translators don't have such ports, and making them null
encourages programs to write on them, possibly expecting that the output
will go somewhere.

It seems to me that the lispy translator should do itself whatever
special work is needed if the lisp system demands the ports be open.  It
is a bug in the lisp system, in fact, if it just crashes in those cases.

Thomas

Re: hurd/libdiskfs ChangeLog dir-lookup.c

[Thomas Bushnell BSG]

On Mon, 2008-06-09 at 21:52 +, Samuel Thibault wrote:
> CVSROOT:  /cvsroot/hurd
> Module name:  hurd
> Changes by:   Samuel Thibault   08/06/09 21:52:12
> 
> Modified files:
>   libdiskfs  : ChangeLog dir-lookup.c 
> 
> Log message:
>   2008-06-06  Samuel Thibault  <[EMAIL PROTECTED]>
>   
>   * dir-lookup.c (diskfs_S_dir_lookup): Unlock np in case of 
> errors.

To be clear, as per my previous message, I would like this change
reverted and replaced with something less destabilizing.

Note that the suggested fix I emailed is not complete: it requires
checking to make sure that the relevant code only happens in the right
places.  (for example, if(newpi) is not exactly kosher since the exit
sequence releases a reference without clearing NEWPI. be careful!)

But I want to add a further note that Samuel's process--while
good--suffers from an important flaw in thinking about locking race
conditions.  When there is a deadlock, there is certainly a bug.  But it
is quite incorrect to simply assume that the correct fix is to unlock
something before the relevant routine is called.

Note that in this case the result is a very dangerous destabilization in
the case taht NP = DNP, where Samuel's patch would result in an extra
unlock.  That could either produce one of those panics that was reported
recently (can't remember by whom), or worse yet, unlocking something
that should be locked with the result that we get directory corruption
errors!

The thought process should have been:
  Oooh, releasing the protid is bad if we are the last reference and
holding the lock; indeed, it is not allowed to release the last
reference if you hold the lock

  So what should we do?  We could (1) release the lock before releasing
the protid, or (2), postpone releasing the protid until later.

Note that (1) changes the way the locking protocol works for possibly
lots of things.  Very destabilizing--even if it happened not to cause a
bug in a particular case.  Option (2) is *guaranteed to be safe*,
because there is no harm in holding a reference longer than you have to.


Thomas

Re: dir_lookup, locking and EINTR

[Thomas Bushnell BSG]

On Fri, 2008-06-06 at 00:12 +0100, Samuel Thibault wrotekfs/dir-lookup.c:478
> 
> dir-lookup.c:478 is as follows:
> 
> 469 if (! error)
> 470   {
> 471 if (flags & O_EXLOCK)
> 472   error = fshelp_acquire_lock (&np->userlock, &newpi->po->lock_status,
> 473&np->lock, LOCK_EX);
> 474 else if (flags & O_SHLOCK)
> 475   error = fshelp_acquire_lock (&np->userlock, &newpi->po->lock_status,
> 476&np->lock, LOCK_SH);
> 477 if (error)
> 478   ports_port_deref (newpi); /* Get rid of NEWPI.  */
> 479   }
> 
> i.e. someone tried to open @test exclusively, but it failed (EINTR),
> and thus we drop newpi.  The problem is that since that's the last
> reference, it cals _ports_complete_deallocate, which ends up calling
> diskfs_release_peropen which tries to acquire the lock on np, which we
> _already_ have, thus the deadlock, which quickly propagates to the /.
> 
> It looks like we have the same problem with diskfs_create_protid().

Your patch (which I see has been applied) seems to be clearly the Wrong
Thing in the case where NP == DNP.  Look at the out: sequence at the end
of the function.  If NP == DNP, we are holding two references to the
node, ("one under each variable name") but only one lock.  You've
released the lock, and the later nput(dnp) will produce only disaster.

I believe your patch is the wrong solution to this problem.  The calling
sequence for diskfs_release_peropen expects to be called only for an
unlocked node.  The right thing to do is to throw NEWPI away at the very
end of the function.

Can you please revert your patch, and put something like the following
in the OUT: sequence right before the return?

if (newpi && error)
  ports_port_deref (newpi);

(and, in the much rarer case where diskfs_create_protid fails, make a
similar adjustment to throw away NEWPO only after the unlocks have
occurred at the end of the function).

Thomas

[Fwd: Gnu Hurd people in the Boston area?]

[Thomas Bushnell BSG]

Perhaps someone can help out John?

Thomas

--- Begin Message ---

Hi, Thomas.

I was looking for information on the current status of GNU Hurd,
to see if I can find someone to give a talk about it at our
Linux and Unix user group. You gave a talk on Hurd at our group
back in 1996, but I see you're no longer in the Boston area.

Are you still involved in the Hurd project, and if so, can you
recommend someone in the Boston area whom I could invite to
give a presentation on the current state of GNU/Hurd?

Thanks.


--
John Abreau / Executive Director, Boston Linux & Unix
IM: [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL 
PROTECTED]
Email [EMAIL PROTECTED] / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--- End Message ---

Re: Thread model

[Thomas Bushnell BSG]

On Wed, 2008-03-19 at 21:48 +0100, [EMAIL PROTECTED] wrote:
> > Now the basic idea behind using one kernel thread to handle several
> > user threads is that when a user thread *would* block, you don't let
> > it block, instead you just take it away and run some other user
> > thread. That works very nicely in Mach, in general, because almost all
> > blocks happen inside mach_msg, and mach_msg was carefully constructed
> > to make this work nicely.
> > 
> > But there is a wrinkle: page faults.  When I say "almost all blocks
> > happen inside mach_msg" that's because one important category does
> > not: page faults.  Or rather, the page fault also blocks in a message
> > send, but the message send is one that is done by the thread in kernel
> > space, rather than by the user space mach_msg, and so the user-space
> > threads library has no access to it.
> 
> I see.
> 
> And pagefault handling can be recursive, and thus just ignoring that
> problem and letting the process block completely is not an option,
> right?

The fault may be handled by the process itself via another thread.

Thomas

Re: Thread model

[Thomas Bushnell BSG]

On Wed, 2008-03-19 at 17:56 +0100, Neal H. Walfield wrote:
> At Wed, 19 Mar 2008 09:58:57 -0400,
> Thomas Bushnell BSG wrote:
> > And throwing a big wrinkle into all that is that many architectures do
> > not make it *possible* for users to handle page faults.  The processor
> > dumps a load of crap on the stack, and the kernel must preserve it
> > carefully and then return the fault.  It is very hard to encapsulate
> > that so that it can be stored and restored by users without keeping the
> > whole stack around.
> 
> L4 was ported to a large number of architectures; it can't be that
> hard.

Sparc or i386?

Or perhaps they are saving the stack frames...

Thomas

Re: Thread model

[Thomas Bushnell BSG]

On Tue, 2008-03-18 at 10:14 +0100, [EMAIL PROTECTED] wrote:
> Hi,
> 
> On Mon, Mar 17, 2008 at 07:00:02PM -0400, Thomas Bushnell BSG wrote:
> 
> > On Sun, 2008-03-16 at 08:25 +0100, [EMAIL PROTECTED] wrote:
> 
> > > We could move the servers one by one -- starting with the disk
> > > filesystems, as this is where the issues are manifesting most...
> > 
> > But this is still not relevant, because the central problem is paging
> > blocks; you have to work that one out first.  That's the one that is a
> > major hassle.
> 
> I must admit that I do not fully understand the relation between
> filesystems and paging yet... Probably this is what I really meant to
> say :-)

Here's what you need to know.

The virtual memory in the process is associated with a "memory object"
which is just a port to some server, normally a file server.  This
association is set up by the vm_map call.  In response, the kernel sets
up memory maps internally, and saves the memory object port provided for
future use.

When a page fault occurs, the thread enters the kernel.  The kernel
recognizes the page fault, looks in the memory maps to find the memory
object in question, computes the right offsets, and then sends a request
to the memory object for the page in question.  When the server responds
with the data, the kernel installs the page in core, adjusts the memory
maps, and returns from the page fault.

Now the basic idea behind using one kernel thread to handle several user
threads is that when a user thread *would* block, you don't let it
block, instead you just take it away and run some other user thread.
That works very nicely in Mach, in general, because almost all blocks
happen inside mach_msg, and mach_msg was carefully constructed to make
this work nicely.

But there is a wrinkle: page faults.  When I say "almost all blocks
happen inside mach_msg" that's because one important category does not:
page faults.  Or rather, the page fault also blocks in a message send,
but the message send is one that is done by the thread in kernel space,
rather than by the user space mach_msg, and so the user-space threads
library has no access to it.

It is hard to see how to fix this without one of the following:

1) Having the kernel know that user threads are multiplexing, and do
some fancy callout stuff when page fault waits occur;
2) Having the user thread handle its own page faults, which would
require some other deep kernel magic.

And throwing a big wrinkle into all that is that many architectures do
not make it *possible* for users to handle page faults.  The processor
dumps a load of crap on the stack, and the kernel must preserve it
carefully and then return the fault.  It is very hard to encapsulate
that so that it can be stored and restored by users without keeping the
whole stack around.

Thomas

Re: Thread model

[Thomas Bushnell BSG]

On Tue, 2008-03-18 at 10:26 +0100, [EMAIL PROTECTED] wrote:
> > You need kernel memory for the memory maps, at least one for each user
> > thread.
> 
> No I don't. That's precisely where it is *not* equivalent.
> 
> In the model I described, the state structures for the blocked requests
> (I prefer not to talk about user threads here -- it's possible to use
> that abstraction, but it only seems to be confusing) are ordinary user
> space data structures, living on the heap. The kernel has nothing to do
> with them.

The heap is demand paged virtual memory, for which the kernel must
maintain memory maps, as Neal was saying.

Thomas

Re: Thread model

[Thomas Bushnell BSG]

On Sun, 2008-03-16 at 08:25 +0100, [EMAIL PROTECTED] wrote:
> Hi,
> 
> On Wed, Mar 12, 2008 at 03:56:47PM -0400, Thomas Bushnell BSG wrote:
> 
> > The clever way is to identify the particular things in the stack which
> > must be saved, and throw the rest away, and then restart the
> > continuation with the few things that really matter.  This is what the
> > kernel does internally; just look for "continuation" and you can see it.
> > You have to identify *each* blocking point, and make a continuation
> > structure for it, and so forth.
> 
> Indeed. I can't tell how much work it is. (Could you give an estimate?)
> 
> But luckily, it doesn't all have to be done in a single sweep. We could
> move the servers one by one -- starting with the disk filesystems, as
> this is where the issues are manifesting most...

But this is still not relevant, because the central problem is paging
blocks; you have to work that one out first.  That's the one that is a
major hassle.

Thomas

Re: Thread model (was: Ext2 superblock fault)

[Thomas Bushnell BSG]

On Sun, 2008-03-16 at 08:52 +0100, [EMAIL PROTECTED] wrote:
> Hi,
> 
> On Tue, Mar 11, 2008 at 11:19:32AM +, Samuel Thibault wrote:
> > [EMAIL PROTECTED], le Tue 11 Mar 2008 04:53:45 +0100, a écrit :
> 
> > > [I] suggested a more adaptive approach: Keep track of the existing
> > > threads, and if none of them makes progress in a certain amount of
> > > time (say 100 ms), allow creating some more threads. But that was
> > > never implemented. Also, it still might cause considerable delays in
> > > some situations; and I'm not even sure it would fix all problems. (I
> > > didn't fully understand the problem discussed in this thread, so I
> > > don't know whether it would be fixed by that?)
> > 
> > The problem I was observing is when you have a sync_all which triggers
> > the write of a lot of files, but unfortunately the superblock was
> > paged out, so that you aren't able to start another thread to reload
> > it. Whatever the thresholds you choose, with a big enough load you
> > will still have the problem of resisting to creating enough threads
> > for all these request, plus one for the superblock reload request.
> 
> So the problem is that a lot of requests get queued before the first one
> gets very far, so that when the superblock read is finally requested, it
> ends up at the end of a long queue?

No, the problem we are talking about is an outright deadlock.

Re: Thread model

[Thomas Bushnell BSG]

On Wed, 2008-03-12 at 20:46 +0100, Neal H. Walfield wrote:
> At Wed, 12 Mar 2008 15:32:26 -0400,
> Thomas Bushnell BSG wrote:
> > On Tue, 2008-03-11 at 12:10 +0100, Neal H. Walfield wrote:
> > > What you are suggesting is essentially using a user-level thread
> > > package.  (Compacting a thread's state in the form of a closure is a
> > > nice optimization, but the model essentially remains the same.)  The
> > > main advantage to user-level thread package is that the thread memory
> > > is pagable and is thus less likely to exhaust the sparser kernel
> > > resources.  In the end, however, it suffers from the same problems as
> > > the current approach.
> > 
> > Cthreads does this.
> 
> Does what?  The cthread implementation found in hurd/libthreads uses
> one kernel thread per user thread.

The old Mach cthreads has a functional feature that multiplexes multiple
user threads on one or more kernel threads.  For the reasons I explain,
we turned this off.  

> > Still, the issue is the thread stacks; even if you are using multiplexed
> > user threads, each user thread still needs a user stack.
> 
> Yes, that is what I tried to say, sorry if it wasn't clear.  My
> suggestion was to use one thread per CPU and to make methods
> restartable so that should an RPC ever need to wait for a resource, we
> just add the message buffer to the object's wait queue (perhaps using
> push-back, e.g., reply to client: try message again using this
> capability, which identifies the wait queue).  When the object becomes
> unblocked, the message is requeued.

This is a risky strategy when there are complicated locks at stake, for
example, in something like diskfs_dir_rename.  Instead of holding one
lock and then waiting on the next (which requires its own proof that the
locking hierarchy is maintained), you hold one lock, try for the next,
and then release both and start over.  You need to prove that there are
no starvation problems, and it's very hard to prove that, because the
technique of a locking hierarchy is no longer sufficient.  There is one
case in diskfs like this (".." traversal), which required me to sort
through all the other multiple-lock cases in diskfs and be sure that
there was no starvation issue.

But, providing you get it right, the way to think about your savings is
this: the easy way stores the continuation as a stack to be resumed.
Your way has the continuation simply be a record of the whole
transaction, which is restarted from the beginning; now you only need to
save one message.

The clever way is to identify the particular things in the stack which
must be saved, and throw the rest away, and then restart the
continuation with the few things that really matter.  This is what the
kernel does internally; just look for "continuation" and you can see it.
You have to identify *each* blocking point, and make a continuation
structure for it, and so forth.  It's not too tough, you eventually just
start writing in explicit continuation passing style.  The code segment
gets bigger though. :)

Thomas

Re: Thread model

[Thomas Bushnell BSG]

On Tue, 2008-03-11 at 12:10 +0100, Neal H. Walfield wrote:
> What you are suggesting is essentially using a user-level thread
> package.  (Compacting a thread's state in the form of a closure is a
> nice optimization, but the model essentially remains the same.)  The
> main advantage to user-level thread package is that the thread memory
> is pagable and is thus less likely to exhaust the sparser kernel
> resources.  In the end, however, it suffers from the same problems as
> the current approach.

Cthreads does this.  Part of the reason we turned off the multiplexing
of user threads on kernel threads was because a paging wait would hold
the whole kernel thread rather than multiplex with another user thread.

Still, the issue is the thread stacks; even if you are using multiplexed
user threads, each user thread still needs a user stack.

Thomas

Re: Ext2 superblock fault

[Thomas Bushnell BSG]

On Mon, 2008-03-10 at 01:19 +, Samuel Thibault wrote:
> 
> This thread is syncing everything, i.e. asking a lot of writes, which
> triggers the creation of a lot of threads.  Unfortunately the superblock
> was paged out, so they all block on reading it.  Unfortunately, since in
> Debian there is a patch which limits the number of created threads,
> the read of the superblock doesn't actually create a new thread, that is
> delayed.  But since none of the existing threads can progress (since
> they are all waiting for the super block), things are just dead
> locked...

As a general rule, the Hurd always assumes that an RPC can be handled;
this is quite emebedded in the way diskfs works.

A patch which limits the number of threads is inherently buggy in the
Hurd, and that patch MUST be disabled for anything to work properly.

> I'm currently using a quite ugly patch (on top of the >2GB patch) to 
> avoid this by just always keeping a copy of the superblock, attached. 
> I'll commit it in the Debian package.

This is not a fix.  This just postpones the problem.  There are many
pagers, all of which must always be able to function.

Thomas

Re: Future of ext2 support in the Hurd?

[Thomas Bushnell BSG]

Currently the plan (approved by RMS) is to keep the Hurd libraries at
"GPLv2 or any later version" so that they can be linked with
Linux-derived code such as ext2fs stuff, and more importantly,
networking stuff.  The Hurd programs themselves (rather than just the
libraries) will be GPLv3, though the transition has not yet happened.

The particular programs that actually use GPLv2-only stuff (ext2fs,
pfinet) will remain as they are.

So thanks for the concern Ted!  It's an important issue, and one that we
think we have worked out correctly.

Thomas




___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Maintenance of the Hurd parts in glibc

[Thomas Bushnell BSG]

On Mon, 2007-07-23 at 02:05 +0200, Thomas Schwinge wrote:
> 
> Getting non-invasive (read: bug-fixing and the like) changes into the
> Hurd's code base is not an issue, as I can do (and actually do) all that.
> For getting invasive (read: interface changes and the like) changes into
> the Hurd we'd need (a) people to come up with such changes (!) and (b)
> have them attract Thomas Bushnell's or Roland McGrath's or Marcus
> Brinkmann's attention (which often enough is not trivial).

If you find such issues, I think that (judging from my own case) the
fastest way to have me respond is to do the following:

1) Call attention to the particular issue, in the subject line
2) Don't ask me to read a big thread

I don't think that long-standing things should go unaddressed, but if
they are pressing concerns, then it's also reasonable to ask for
pressing attention.

Thomas




___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Defualt socket server overriding

[Thomas Bushnell BSG]

On Wed, 2007-06-20 at 16:20 +0200, Neal H. Walfield wrote:
> What is a pseudo-chroot?
> 
> I think what you are proposing is essentially filtering the global
> name space via some fancy translator.  

Yes, just that.

> When we are just interested in
> overriding a small parts of the environment and the rest represents a
> reasonable default, this may be fine.  Such an approach is, however,
> completely contrary to POLP.  I think the right direction is private
> name spaces, which can be achieved by passing capabilities.  That was
> the other part of my suggestion.

Private namespaces are another excellent idea; they are perhaps harder
to work into the current framework unless there's a trick I haven't
thought of.

I'm not trying to dampen the env-variable trick too; let a thousand
flowers bloom!

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Defualt socket server overriding

[Thomas Bushnell BSG]

On Wed, 2007-06-20 at 11:11 +0800, Wei Shen wrote:
> Hi,
> 
> On 6/20/07, Neal H. Walfield <[EMAIL PROTECTED]> wrote: 
>  
> > (1) Add a set of new environment variables, e.g.
> PFINETSERVER for the pf_inet server and PFLOCALSERVER for the
> pf_local server. 
> 
> We should have consistent naming between node names and
> environment variables.  The default node names
> are /servers/socket/{2,pfinet}, etc.  Perhaps have
> SERVERS_SOCKET_PFINET be the name of the environment variable
> to use.

I wonder how you plan to implement this.  The library does not use 
the #define symbol in practice; it uses /servers/socket/%d and fills in
%d from the first argument to the socket() call.

It seems to me that an implementation which makes assumptions about how
people construct names in /servers is unreliable.

What about a different strategy, one more "hurdish"?  For example, run
the program in a pseudo-chroot which overrides the behavior of nodes
inside /servers?

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: GPLv3 and Hurd? (also a possible license violation)

[Thomas Bushnell BSG]

Ok, thanks Thomas.

First you list the files with the UU copyright, including advertising
clause.  Roland is going to ask Utah about those.

Then you list some with BSG copyright, including advertising clause.  We
already have permission from Berkeley to remove the clause from such
files.  Can someone take charge of doing so?

> pfinet/linux-src/include/linux/if_ppp.h
> pfinet/linux-src/include/linux/if_pppvar.h
> pfinet/linux-src/include/net/slhc_vj.h
> 
> Those files state:
> 
> #v+
>  * Redistribution and use in source and binary forms are permitted
>  * provided that the above copyright notice and this paragraph are
>  * duplicated in all such forms and that any documentation,
>  * advertising materials, and other materials related to such
>  * distribution and use acknowledge that the software was developed
>  * by Carnegie Mellon University.  The name of the
>  * University may not be used to endorse or promote products derived
>  * from this software without specific prior written permission.
> #v-

This does not contain any noxious clauses, and is already GPL-compatible as it 
stands.
> #v+
>  * Redistribution and use in source and binary forms are permitted
>  * provided that the above copyright notice and this paragraph are
>  * duplicated in all such forms and that any documentation,
>  * advertising materials, and other materials related to such
>  * distribution and use acknowledge that the software was developed
>  * by the University of California, Berkeley.  The name of the
>  * University may not be used to endorse or promote products derived
>  * from this software without specific prior written permission.
> #v-

Likewise, this is GPL compatible as it stands.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: GPLv3 and Hurd? (also a possible license violation)

[Thomas Bushnell BSG]

On Sat, 2007-06-16 at 18:49 -0400, Michael Casadevall wrote:
> I did cite one such case already, from cons.c (it appears in quite a  
> few other files as well), and Thomas cited one as well.
> 
> (3) all advertising
> * materials mentioning features or use of this software display the  
> following
> * acknowledgement: ``This product includes software developed by the
> * Computer Systems Laboratory at the University of Utah.''

I didn't see that in your post.  As Roland said, we have friends at
Utah, and there is every reason to think they will simply give us
permission to remove the naxious advertising clause.  Let's proceed on
the assumption that this is true for now.

Roland, can you talk to Jay or whoever is appropriate?

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: GPLv3 and Hurd? (also a possible license violation)

[Thomas Bushnell BSG]

On Sat, 2007-06-16 at 14:52 -0400, Michael Casadevall wrote:
> I had emailed Thomas in regards to this because I didn't want to start
> a general panic over the license. Anyway, we have a few problems in
> any regard (I'm a Savannah Administrator, and if we have to remove the
> GPL later clause, then we're in violation of Savannah's hosting
> policy)

Once more, I seem to have taken your word for it when I shouldn't have.

The link you provided, to
https://savannah.gnu.org/maintenance/GnuGplTwoOrLater, certainly does
request people to use the "or any later version" clause.  Well and good.

Nothing there, however, says that projects *must* use it as a condition
of being hosted on Savannah.

I do hope you are not using your position to attempt to strongarm people
into following rules that do not actually exist.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: GPLv3 and Hurd? (also a possible license violation)

[Thomas Bushnell BSG]

On Sat, 2007-06-16 at 14:52 -0400, Michael Casadevall wrote:

>  * Permission to use, copy, modify and distribute this software and
> its
>  * documentation is hereby granted, provided that both the copyright
>  * notice and this permission notice appear in all copies of the
>  * software, derivative works or modified versions, and any portions
>  * thereof, and that both notices appear in supporting documentation.

Sorry, I took your word for it when I sholudn't have.

Nothing here, which you attribute to UU, contains the noxious
advertising clause.

I do recall that such files did once exist, but this notice is not it.
Notice, you see, that it does not refer to advertising.

If there are such notices, can you please post one?  I can ask Utah
about it, and my guess is that this is all old enough that they won't
care at all, and will happily follow BSD's example and allow its
removal. 

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: GPLv3 and Hurd? (also a possible license violation)

[Thomas Bushnell BSG]

On Sat, 2007-06-16 at 14:52 -0400, Michael Casadevall wrote:
> 
> The problem stems from the fact that the GPL is a project-wide
> license, it's not per-file (the CDDL and MPL are per file; they aren't
> viral licenses). Simply having it in one file binds the entire project
> to that license which would replace BSD license (assuming of course
> that we can somehow get rid of the adversing clause line). We right
> now have conflicting licenses between the Linux code, and the Hurd
> code; we need to get it all standardized to ONE license, and the later
> clause will allow us to go to GPLv3 (there is one other big reason why
> we need this).

This is not quite true.  The GPL is project-wide, and a project can be
distributed only under the terms of the most restrictive project-wide
license.  So there is nothing legally problematic with having some files
that say "or any later version" and some that do not.  The problem (such
as it is) is that GPLv3 doesn't apply to such a project.  This is worth
some effort to try and fix, but it's not a disaster: and so the effort
must be weighed against the benefits received.

Note that the copright notice on the file *is* a per-file thing; it is
*not* a per-project thing, nor could it be.  What it says is "you can
copy this *file*, provided your copying of the *project* meets the
specified version of the GPL."  If some files say "GPLv2", and some say
"GPLv2 + any later version", then anyone who copies the project under
the terms of GPLv2 is on solid legal ground.

> The last problem is Savannah's hosting policy requires the "or any
> later version" clause if a project is licensed under GPLv2, and
> Savannah will remove projects that doesn't follow this restriction
> (https://savannah.gnu.org/maintenance/GnuGplTwoOrLater)

Savannah is a NOP.  We should not be exercised about where things are
hosted, nor allow that to control decision making.  There are plenty of
free hosting options for free software projects, that we should not
worry about whether it's at Savannah or not.

> What we need to do (WRT to "or later" clause):
> 1. Remove the "or later clause" and get copyright holders permission
> to do so (and then go find new hosting since we'll have to leave
> Savannah unless they are willing to make an exception for us)

As I say, this is not necessary.  There is an advantage to *adding* "or
any later version", if we can get it on every contribution, because then
we could specify GPLv3.  But there is no advantage to *removing* it.

> 2. Remove the Linux code, and replace it with a BSD driver wrapper,
> then add the "or later clause" to the sections of Mach; the BSD
> licensing code meets Savannah hosting standards and is compatiable 

We cannot go adding clauses to the sections of Mach.  The copyright
owners are, for all intents and purposes, gone.

> The last issue is the advertising clause; by all standards this
> conflicts with the GPL code. If mach was released without the clause
> at some point, and these copyright messages are simply artifacts we
> can just remove them; if not, we may have to go to University of Utah
> and try and get them to re-release without that copyright notice. In
> an attempt to determine the legal state of the license, I went back in
> time, and found a copy of mach4 before it became GNU mach, and look at
> their license. University of Utah attached the following license to
> their files (there is also one under it for the standard Berkeley
> license):

The advertising clause, FWIW, only causes a problem in the UK.  However,
it does cause a real problem there, and so we should address it.  What
we need to do is simply to ask Utah for blanket permission such as UC
has granted for the BSD stuff.

> In regards to the BSD adversing clause, this is our choices:
> 1. If a prior legal agreement was worked out between the FSF and CMU,
> we simply need to fix all the copyright notices in the code. I'm
> PRAYING this is the case because the other options are fairly
> nasty :-/

The CMU code does not impose any restrictions upon us, and RMS
explicitly agreed that back when it was first changed to what you see
now.  (It used to have a requirement that changes be contributed back,
which is of course problematic.)

> 2. We comply with CMU's license. This means all GPL code added to mach
> itself needs to be relicensed, and we have to scrap the remaining GPL
> code. In addition, we need to add the required adversing clause to
> EVERYTHING (I'm not even sure this qualifies as free software by FSF
> definition).

What are you talking about?  What "compliance" exactly are you asking
for?  The CMU license imposes only one condition: that the copyright
notice and permission grant be retained on all copies.  

> It looks like CS students decided to use Linux drivers without
> checking the license, and when Mach was forked, no one bothered to
> check the original license. I'm a little upset that I found this
> because if we can't resolve both these issue, I effectiv

Re: Do we want a server on `/servers/machine' (or similar)?

[Thomas Bushnell BSG]

On Fri, 2007-05-11 at 23:45 +0200, Thomas Schwinge wrote:
> Hello!
> 
> On Thu, May 10, 2007 at 07:32:31PM -0700, Thomas Bushnell BSG wrote:
> > Um, well, you could keep track of the relationship, and establish the
> > rule that a user of i386_io_perm_create sent to this special server must
> > keep the request port open as long as they want the mapping to stay
> > alive.  
> 
> Wouldn't there be a way to just _move_ the send right to the freshly
> created i/o permission kernel object to the target task (which is the
> requesting task in this case)?  So far, I haven't been able to figure out
> how to do that correctly.
> 
> Requestee R invokes `i386_io_perm_create' on the server S,
> `/servers/io_perm'.  S invokes `i386_io_perm_create' on the device-master
> port, which returns a new handle H to a freshly created kernel object.
> Then S _moves_ H to R (*HOW?*) so that S itself won't reference H
> anymore.  Then, as soon as R dies, H will become invalid and the kernel
> will receive a no-senders notification.  Wouldn't it work that way?

Why not just reply with the right that the kernel has handed S?




signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Do we want a server on `/servers/machine' (or similar)?

[Thomas Bushnell BSG]

On Fri, 2007-05-11 at 00:50 +0200, Thomas Schwinge wrote:
> [Remove hurd-devel.]
> 
> 
> Hello!
> 
> In the server T (`/servers/ioperm') I essentially have...
> 
> #v+
> kern_return_t
> S_i386_io_perm_create (mach_port_t port, io_port_t from, io_port_t to,
>mach_port_t *io_perm)
> { 
>   kern_return_t err;
> 
> [Do some checks on PORT.]
> 
>   err = i386_io_perm_create (devmaster, from, to, io_perm);
> 
>   return err;
> }
> #v-
> 
> ... to serve invocations of `i386_io_perm_create' on T and -- after the
> needed checking -- pass the request to the device-master port, invoking
> `i386_io_perm_create' on there.  This works.
> 
> But there is one problem.  If the requestee (the program that invoked
> `i386_io_perm_create' on T) terminates, the server T won't (tell the
> kernel to) destroy the resources that have been allocated by invoking
> `i386_io_perm_create' on the device-master port.  This is because there
> is no association between the port `port' and these resources.  How to
> establish such a relationship?
> 
> If `port' becomes dead, `io_perm' should be deallocated as well, but how?

Um, well, you could keep track of the relationship, and establish the
rule that a user of i386_io_perm_create sent to this special server must
keep the request port open as long as they want the mapping to stay
alive.  

This suggests that it's not the best idea to reuse the name since the
semantics are shifting, which perhaps also makes an opening to have a
more generic interface.  (On the other hand, other processors don't have
anything like 386 IO registers, so maybe it's not worth it.)

As for separating the memory access and the IO ports, is there any
reason to want to combine them?

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Do we want a server on `/servers/machine' (or similar)?

[Thomas Bushnell BSG]

On Fri, 2007-05-11 at 00:06 +0200, Thomas Schwinge wrote:
> Now, if Roland suggests to separate the i/o port and memory access
> interfaces then we could (for example) simply have the suggested
> `/servers/ioperm' and a `/servers/mem' (or `/dev/mem'? -- but our thing
> is more advances than the usual Unix system's `/dev/mem' is, so we'd
> rather put it into `/servers/', I think).

/dev/mem is a specific thing; writes to /dev/mem are supposed to write
physical memory addresses directly.  Nothing prevents such an interface
being used for this purpose, but it doesn't seem to me that it would be
possible to have fine-grained control over /dev/mem and still maintain
that interface.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Do we want a server on `/servers/machine' (or similar)?

[Thomas Bushnell BSG]

On Wed, 2007-05-09 at 17:53 +0200, Thomas Schwinge wrote:
> Now, how about the following: we have a server sitting on
> `/servers/machine' (or somewhere else) that accepts rpcs like
> `io_perm_create' or `memory_map_create' and ``forwards'' (it need not
> really be forwarding) them to the kernel after having done some
> permission checking.  That server would hold access to the device-master
> port (and host-priv as well?), so it could also -- being a proxy -- allow
> access to (e.g.) `i386_io_perm_create' to users that can't get such
> access by themselves, but can prove that they should be allowed such
> access.  Proving this might be something like: ``When you're a member of
> the `console' group, you're allowed to get access to the i/o ports that
> deal with video output and to the video memory.''

I think this is roughly the right structure, sounds good.

I don't much like the name /servers/machine; so let's figure out
something better.  Names like that persist forever, so it's actually
more important than it might seem to get them right from the get-go.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Setting ones's priorities (was: My proposal for `PATH_MAX' and friends)

[Thomas Bushnell BSG]

On Wed, 2007-04-11 at 12:57 +0200, Thomas Schwinge wrote:
> Hello!
> 
> On Tue, Apr 10, 2007 at 10:10:01PM -0700, Thomas Bushnell BSG wrote:
> > On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote:
> > > We're still being again and again annoyed by programs that use `PATH_MAX'
> > > unconditionally.
> > 
> > Why stop with this one?
> 
> So, if I interpret things correctly you essentially say that you'd rather
> want me to fix other peoples's software (like the git rcs) instead of
> fixing our own software (like trying to trace that new libdiskfs dead
> lock I just found)?  Having me do both is not possible genereally,
> because my time is limited.

No, you should spend your time on the Hurd, because there are fewer
people that can do that work.  Keep track of programs that have PATH_MAX
or access(NULL) problems, and when people say, "how can I help", we can
point them at this list.

File Debian bug reports on the Debian packages concerned.  Let the
Debian maintainers cope with dealing with upstream (after all, it's what
they have volunteered for).

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

[Thomas Bushnell BSG]

On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote:
> Hello!
> 
> We're still being again and again annoyed by programs that use `PATH_MAX'
> unconditionally.

Why stop with this one?  Let's just drop all the Hurd features and
implement the same interface as Linux, as exactly as we can make it.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: What is ``access (NULL, whatever)'' supposed to do?

[Thomas Bushnell BSG]

On Tue, 2007-04-10 at 11:46 +0200, Neal H. Walfield wrote:
> At Mon,  9 Apr 2007 20:02:32 -0700 (PDT),
> Roland McGrath <[EMAIL PROTECTED]> wrote:
> > 
> > It is supposed to crash.  Hopefully it does not hold locks while doing so,
> > and we should make sure that it doesn't.  But anything that returns EFAULT
> > on Linux has every right to crash with SIGSEGV or SIGBUS there too, and on
> > the Hurd we explicitly intend that bad addresses cause crashes and not
> > errors that might be ignored.  If it's undefined behavior, crashing quickly
> > is the most humane way to treat the disadvantaged programmer who made an
> > error or truly didn't know better before.  
> 
> This is a nice approach in theory but in practice it fails for us
> because the programmers who make these mistakes do not see the
> crashes: few programmers develop natively on the Hurd or even test
> their code on the Hurd.  As such, ignoring that this behavior has
> become de facto only creates work for Hurd porters.  Let these people
> make more substantial contributions than correcting technical but
> otherwise benign, pedantic bugs.

These are not in general benign bugs.  Rather, they are lucky.  Often
such bugs are related to security failures, or are causing more serious
bugs elsewhere in ways which are very difficult to reproduce.  Handing
around bad pointers and the like is not a good strategy for code, and
the fact that the Hurd has this different behavior is only good.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: libtrivfs broken?

[Thomas Bushnell BSG]

On Tue, 2007-02-20 at 00:46 +0100, Richard Braun wrote:
> On Mon, Feb 19, 2007 at 03:38:04PM -0800, Thomas Bushnell BSG wrote:
> > The node doesn't "belong to the user"; the filesystem does not know or
> > care what access permissions are there in the upper-level filesystem.
> > It is in *that* filesystem which the user is marked the owner; not in
> > the running trivfs filesystem.
> > 
> > So you need to ask the upper level filesystem for it: since you are the
> > owner of the upper-level node, you can call file_getcontrol on the
> > upper-level node.
> 
> I understand the point. But calling file_getcontrol() on the upper-level
> node won't allow us to update the options of the trivfs translator AIUI.
> Isn't there a way to do that without being root ?

I apologize; I meant you should call file_get_translator_cntl on the
upper-level node.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: libtrivfs broken?

[Thomas Bushnell BSG]

On Tue, 2007-02-20 at 12:10 +0100, Richard Braun wrote:
> On Mon, Feb 19, 2007 at 05:21:29PM -0800, Thomas Bushnell BSG wrote:
> > On Tue, 2007-02-20 at 00:46 +0100, Richard Braun wrote:
> > > I understand the point. But calling file_getcontrol() on the upper-level
> > > node won't allow us to update the options of the trivfs translator AIUI.
> > > Isn't there a way to do that without being root ?
> > 
> > Yes it will; it will give you the fsys handle for the active translator:
> > the trivfs translator here; then you can call fsys_* on it.
> 
> I see, but it's not what fsysopts does anyway : it first calls
> file_name_lookup() to get a handle on the node and then
> file_getcontrol() on this handle. There is no way to make this call
> on the parent using fsysopts, is there ?

I don't know.  I agree completely that there is a bug, just that
changing trivfs seems like the wrong thing.  I think fsysopts should try
both ways to get the handle, since either one might work and not the
other.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: libtrivfs broken?

[Thomas Bushnell BSG]

On Tue, 2007-02-20 at 00:46 +0100, Richard Braun wrote:
> I understand the point. But calling file_getcontrol() on the upper-level
> node won't allow us to update the options of the trivfs translator AIUI.
> Isn't there a way to do that without being root ?

Yes it will; it will give you the fsys handle for the active translator:
the trivfs translator here; then you can call fsys_* on it.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: libtrivfs broken?

[Thomas Bushnell BSG]

On Tue, 2007-02-20 at 00:23 +0100, Richard Braun wrote:
> > What makes you think that's a bug?
> 
> I don't know if it's a bug actually, I mentionned I wanted to study the
> problem. Still, it seems weird that fsysopts isn't able to get the control
> of a node which belongs to the user. Any reason for this behaviour ?

The node doesn't "belong to the user"; the filesystem does not know or
care what access permissions are there in the upper-level filesystem.
It is in *that* filesystem which the user is marked the owner; not in
the running trivfs filesystem.

So you need to ask the upper level filesystem for it: since you are the
owner of the upper-level node, you can call file_getcontrol on the
upper-level node.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: libtrivfs broken?

[Thomas Bushnell BSG]

On Mon, 2007-02-19 at 23:13 +0100, Richard Braun wrote:
> On Mon, Feb 19, 2007 at 04:58:24PM -0500, Ben Asselstine wrote:
> > Hello,
> > 
> > I ran across this behaviour recently.  It works if I do the same as
> > the root user.  Is anyone else having this problem?
> > 
> > v+
> > [EMAIL PROTECTED]:/tmp/bing$ settrans -ac yoyo /hurd/hello --contents="yoyo"
> > [EMAIL PROTECTED]:/tmp/bing$ cat yoyo
> > [EMAIL PROTECTED]:/tmp/bing$ fsysopts yoyo --contents="yaya"
> > fsysopts: yoyo: Operation not permitted
> 
> I had this problem when working on the BPF translator, and was wanting to
> look deeper before reporting, then I forgot :-(.
> 
> The faulty code is in hurd/libtrivfs/file-getcontrol.c :
> 
> kern_return_t
> trivfs_S_file_getcontrol (struct trivfs_protid *cred,
> ...
> {
> ...
>   if (!cred->isroot)
> return EPERM;
> ...
> }

What makes you think that's a bug?


signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: An idea and proposal about system time

[Thomas Bushnell BSG]

On Sat, 2007-02-17 at 11:06 +0100, Thomas Schwinge wrote:
> Looking at the source code, I see that it is used inside `pfinet' for
> timing issues and a few times in the file system servers.

These "few times" are crucial; every single time a file access is
performed, a timestamp needs to be marked in the inode for the file.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Copyright information

[Thomas Bushnell BSG]

On Mon, 2007-02-05 at 21:45 +0100, Thomas Schwinge wrote:
> Hello!
> 
> Mach files have copyright headers like this:
> 
> #v+
> /*
>  * Mach Operating System
>  * Copyright (c) 1993-1987 Carnegie Mellon University.
>  * Copyright (c) 1993,1994 The University of Utah and
>  * the Computer Systems Laboratory (CSL).
>  * All rights reserved.
> [...]
> #v-
> 
> Why haven't there been added lines like ``Copyright (C) 2000 FSF'' when
> the Hurd people changed these files?


1: We have never worried about the paper trail for Mach sources, because
it's like trying to nail jello to a tree.

2: We adopted the policy that we were not going to GPL our own work on
Mach because then it could be more easily shared with the rest of the
community.

3: Most of our changes have been small enough that it's not clear that
we have a real claim to make.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [task #5490] syslog

[Thomas Bushnell BSG]

On Thu, 2007-02-01 at 00:22 +0200, Constantine Kousoulos wrote:
> 
> It's nice to know the direction the implementation is headed. I 
> would be grateful if you could supply links that further document 
> the above mentioned statement. To be honest, i had the exactly 
> opposite idea since it has been mentioned that the Coyotos kernel 
> was a candidate to replace the Mach kernel and Coyotos has an 
> asynchronous design.

If we rely on asynchronous messaging, then we are stuck when a
synchronous system comes around.  

If we rely on RPC, then asynchronous systems (like Mach and Coyote)
implement RPC, and do so as a major efficiency priority.
> 
> Regarding the syslog problem, what can be done? From what has been 
> said so far, the intermediate translator solution is not optimal. 
> Do we use syslog as it is but carefully because of the internal 
> locking? If so, this task should be deleted.

In my opinion, we should use syslog() as it is, and the work necessary
is to make sure that the servers which get invoked in the course of
processing a syslog() call do the right thing.  As I said, this is
really only an issue at bootstrapping time and for non-multi-threaded
servers; and that every server should be careful to call syslog only
outside locks.

Even using asynch messages in Mach would not necessarily be sufficient
to avoid the deadlock problem; note that asynch sends in Mach normally
block if the recipient's message queue is filled.

> How about this: what if the syslog daemon was rewritten as a 
> syslog translator capable of handling the locking issue?

I don't see what that means; the point is that things like syslog
shouldn't be called within critical sections, and that if one has
avoided that, normal multi-threaded servers should have no trouble using
syslog().

If they *do* have such trouble, then this needs to be sorted out.


signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [task #5490] syslog

[Thomas Bushnell BSG]

On Wed, 2007-01-31 at 19:13 +0200, Constantine Kousoulos wrote:
> typo corrections... @!#$&*!!
> 
> Thomas Bushnell BSG wrote:
> > I cannot see any reason why, once the system is up and running, even
> > proc cannot simply syslog just like anything else, provided it does not
> > hold internal locks as it does so (and this should be true for *every*
> > call to syslog anyhow, in whatever program).
> > 
> 
> I can see how internal locking is important. However, by using
> another translator to call syslog instead of the original (eg
> logrelay instead of proc) don't we bypass the problem? Syslog does
> lock but from within logrelay, leaving proc free to continue doing
> whatever was doing. All proc did was send an asyncronous message
> to logrelay which i don't think it blocks proc's operation much.

We generally tend to dislike the use of asynchronous messages.  They are
great for Mach, but we would like to avoid the need to use them in
general.

Keeping things always as RPCs makes the system much more likely to be
portable in the future to other kernels.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [task #5490] syslog

[Thomas Bushnell BSG]

On Wed, 2007-01-31 at 00:03 +0100, [EMAIL PROTECTED] wrote:
> An interesting idea, though it doesn't really help with the problem at
> hand: This thread (and I think the task it refers to) isn't about
> logging from normal translators (which wouldn't need any special
> facility to use syslog() in the canonical way), but from the low-level
> Hurd servers.

Let's be clear what we mean by "low-level Hurd servers".  The filesystem
and pflocal are not such cases, except as they are starting up.

We only need to worry, in fact, about cases where deadlock actually can
occur; the most clear example is for non-multi-threaded servers.  Are
there any left?

The other case is where the details of implementation produce a
deadlock.  For the servers concerned we should satisfy ourselves that no
deadlock occurs, and then proceed.

I cannot see any reason why, once the system is up and running, even
proc cannot simply syslog just like anything else, provided it does not
hold internal locks as it does so (and this should be true for *every*
call to syslog anyhow, in whatever program).

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [task #5490] syslog

[Thomas Bushnell BSG]

I see no reason why we should care about emulating klog.

Hurd translators can, in general, perfectly well simply write directly
to the regular /dev/log socket in the regular way.  Heck, even the
filesystem and pflocal translators can do so, since they are properly
multi-threaded.

The only issue that needs to be addressed is a bootstrapping time one
here.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: notify_no_senders oddity

[Thomas Bushnell BSG]

On Mon, 2007-01-01 at 23:05 +0100, Samuel Thibault wrote:
> Ok, that I can understand, but the code snippet I showed doesn't pass
> through MiG, it's just a function call:
> 
> kern/ipc_kobject.c:ipc_kobject_notify():
> ipc_port_t port = (ipc_port_t) request_header->msgh_remote_port;
>   ...
> switch (ip_kotype(port)) {
> case IKOT_DEVICE:
> return ds_notify(request_header);
> 
> and i386/i386at/i386at_ds_routines.c:ds_notify():
> 
> ds_notify (mach_msg_header_t *msg)
> {
> ...
> dev = (device_t) msg->msgh_remote_port;
>   if (dev->emul_ops->no_senders)
> 
> > > Both types are used for the same port.
> > 
> > Yes, so?
> 
> They're of incompatible type (neither can cast to the other one), while
> ip_kotype(port) wants ipc_port_t and dev->emul_ops wants device_t.
> 
> Just to be really clear: the code snippet above, given some msg, first
> considers its msgh_remote_port member as an ipc_port_t, and _uses_ it
> as such (reading its ip_object member), and then calls ds_notify, which
> itself considers msgh_remote_port as a device_t, and _uses_ it as such
> (reading its emul_ops member).  I fail to see how this can ever work.

My source (have things changed here in some material way?) does not have
i386/i386at/i386at_ds_routines.c.  It has oskit/ds_routines.c, which
has:

boolean_t
ds_notify (mach_msg_header_t *msg)
{
  if (msg->msgh_id == MACH_NOTIFY_NO_SENDERS)
{
  device_t dev;
  mach_no_senders_notification_t *ns;

  ns = (mach_no_senders_notification_t *) msg;
  dev = dev_port_lookup ((ipc_port_t)
ns->not_header.msgh_remote_port);
  assert (dev);

  /* Extant send rights held one ref on the device object,
 and we just got another one from dev_port_lookup.  */
  device_deallocate (dev);
  device_deallocate (dev);

  return TRUE;
}
  printf ("ds_notify: strange notification %d\n", msg->msgh_id);
  return FALSE;
}


Notice that this routine does not simply cast the remote point, but
looks it up in the table of device ports.

 




signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: notify_no_senders oddity

[Thomas Bushnell BSG]

On Mon, 2007-01-01 at 22:48 +0100, Samuel Thibault wrote:
> Thomas Bushnell BSG, le Mon 01 Jan 2007 12:18:17 -0800, a écrit :
> > > > >   bd->port = ipc_port_alloc_kernel ();
> > > > >   ipc_port_nsrequest (bd->port, 1, notify, ¬ify);
> > > > > 
> > > > >   dev = (device_t) ns->not_header.msgh_remote_port;
> 
> > The MiG converters for the various types are not identical.  
> 
> But how is the differenciation done in this case?

The mig .defs file declares a port for the argument, and when MiG
generates the server side stub, it automagically calls a function
declared for that type between the RPC reception and the server
function.

> Both types are used for the same port.

Yes, so?

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: notify_no_senders oddity

[Thomas Bushnell BSG]

On Mon, 2007-01-01 at 20:08 +0100, Samuel Thibault wrote:
> Richard Braun, le Mon 01 Jan 2007 17:47:32 +0100, a écrit :
> > On Mon, Jan 01, 2007 at 11:49:54AM +0100, Samuel Thibault wrote:
> > > Ok, and how these two views may coexist?  As I showed, they _are_ mixed
> > > in the case of the linux block device glue for instance:
> > > linux/dev/glue/block.c:device_open():
> > > 
> > >   bd->device.emul_data = bd;
> > >   bd->device.emul_ops = &linux_block_emulation_ops;
> > >   ...
> > >   bd->port = ipc_port_alloc_kernel ();
> > >   ...
> > >   notify = ipc_port_make_sonce (bd->port);
> > >   ip_lock (bd->port);
> > >   ipc_port_nsrequest (bd->port, 1, notify, ¬ify);
> > > 
> > > 
> > > So here it's really a plain IPC port that is used (and it's the same in
> > > the plain device/ds_routines.c, linux net glue and pcmcia glue), while
> > > on the other end: i386/i386at/i386at_ds_routines.c
> > > 
> > >   dev = (device_t) ns->not_header.msgh_remote_port;
> > > 
> > > How can this work?  (I currently have a kernel fault here)
> > 
> > I guess it's because the device_t type is defined to something else
> > for i386 devices :
> 
> No objection to that, since that's precisely what Thomas said.  But just
> to repeat myself: as quoted above linux block/net/pcmcia devices and
> mach devices provide an IPC port, not a device_t!

ah, I recall now.

The MiG converters for the various types are not identical.  

The way this can work is by the kernel making sure that the kernel name
for the port is the same as the address of its internal record keeping
structure.  This approach was much beloved by the Mach designers.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: notify_no_senders oddity

[Thomas Bushnell BSG]

On Mon, 2007-01-01 at 11:49 +0100, Samuel Thibault wrote:
> Hi,
> 
>   dev = (device_t) ns->not_header.msgh_remote_port;
> 
> How can this work?  (I currently have a kernel fault here)

A device_t and a mach_port_t are exactly the same data type, both are
just integers, unless I am confused. 

However, if there is a fault on the line of code indicated above, I
would guess that NS is pointing somewhere bogus.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: notify_no_senders oddity

[Thomas Bushnell BSG]

On Sun, 2006-12-31 at 12:30 +0100, Samuel Thibault wrote:
> Hi,
> 
> There's something I don't understand in
> i386/i386at/i386at_ds_routines.c:ds_notify()
> 
>   dev = (device_t) ns->not_header.msgh_remote_port;
> 
> How a port can be a device_t?

A device_t is just a mach_port_t that is expected to be talking to
something that implements the Mach device protocol.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Signals, messages and exceptions

[Thomas Bushnell BSG]

On Fri, 2006-12-01 at 15:03 -0300, Leonardo Pereira wrote:
> I think he isn't, Mach Exceptions are just another aproach of signals,
> they were used on Mach_US and Lites to implement Unix-compatible
> signals. The unique 'problem' is that Mach Exceptions handle not only
> process but also threads, so, this is a very fundamental difference.

No, both you and Igor are missing the point.  Mach exceptions are *also*
just messages sent between tasks.  Igor seems to think that there is
some "duplication" going on, when in fact, we have a Mach thing (an
exception) which we need to reflect as a Posix signal for programs that
only know about signals.

It is obligatory to map Mach exceptions to signals, because Posix-aware
and Mach-ignorant programs should get the expected signals for machine
faults and the like.

However, a program that understands Mach exceptions is certainly able to
handle the exceptions itself, directly, by putting its own exception
handler in place and then libc's (which does the mapping) will not be
used.  One can even arrange to handle some exceptions yourself, and
forward the others on to the default handler in libc.

Leonardo is missing the point, in thinking that exceptions are another
approach to signals; they are in fact fundamentally different.  When a
Mach thread encounters an exceptional condition, the thread is
suspended, and a message is sent.  The message can be handled by
anything else in the system, with one exception: it cannot be handled by
the faulting thread, because that thread is suspended.

Posix signals are not like this at all; a Posix signal does not suspend
anything; instead, the exceptional condition is handled on the stack of
the faulting process by directly munging its instruction pointer and
such.  This has all kinds of problems, and the cleanliness and sanity of
the Mach approach is clearly the right way to go in a multi-threaded
system with message passing.

However, that doesn't mean we can ignore Posix.  Igor sees duplication,
but I wonder what he thinks should happen when a process gets a Mach
exception, for ordinary programs which do nothing special.

Thomas




signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [bug #17346] GNU mach can't handle 4GB memory

[Thomas Bushnell BSG]

On Mon, 2006-11-20 at 16:15 +0200, Constantine Kousoulos wrote:
> All the above solutions aim to make Mach unaware of any memory 
> above 1 GB. Isn't it possible to utilise all the memory? I will 
> explain myself.

I think this is clearly right, but it may well require more substantial
changes to actually make it work.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Gnumach cleanup Round 6

[Thomas Bushnell BSG]

On Wed, 2006-11-15 at 15:55 -0500, Barry deFreese wrote:
> >   
> Thomas,
> 
> Thanks for the reply.  Are you saying I should wrap those includes 
> around an #ifdef MACH_KDB up where the other includes are?  If so, that 
> makes sense to me.

I did not check whether the MACH_KDB check is right.  But on the
assumption that it is, yes, it still belongs up above.  I think the very
next file after this one in your patch was an example of it done right.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Gnumach cleanup Round 6

[Thomas Bushnell BSG]

On Wed, 2006-11-15 at 13:43 -0500, Barry deFreese wrote:
> Hi folks, it's your favorite PITA again.. :-)

> Index: i386/i386/trap.c
> ===
> RCS file: /cvsroot/hurd/gnumach/i386/i386/trap.c,v
> retrieving revision 1.5.2.6
> diff -u -p -r1.5.2.6 trap.c
> --- i386/i386/trap.c  11 Nov 2006 00:54:05 -  1.5.2.6
> +++ i386/i386/trap.c  15 Nov 2006 17:15:58 -
> @@ -60,6 +60,8 @@ extern void thread_exception_return();
>  extern void i386_exception();
>  
>  #if  MACH_KDB
> +#include 
> +#include 
>  boolean_tdebug_all_traps_with_kdb = FALSE;
>  extern struct db_watchpoint *db_watchpoint_list;
>  extern boolean_t db_watchpoints_inserted;


The #includes should go at the front, with the rest of the <> includes.
Preserve the normal order:

#include <>
...
#include ""
...
other decls
...
functions

except when there is a good reason to deviate, which there does not seem
to be in this case.

Thomas



signature.asc
Description: This is a digitally signed message part
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd