Re: About merging the Hurd homepage and the Hurd wiki

[Barry deFreese]

Thomas Schwinge wrote:

Hello!

It has been my plan for a long time, but needed to much work effort to be
done immediatelly.  So I postponed it.  Has now perhaps the time come to
revisit this topic, in context of just having lost http (port 80) access
to the machine hosting the Hurd wiki?

Driving both a homepage, , that is very
infrequently updated, plus a wiki, (read-only mirror available at
), that gets some more
care, seems a bit too much.  So what about merging them?


  



Regards,
 Thomas
  

Thomas,

I'm really fine either way.  I feel really bad that this has happened as 
I was told by some colleagues that Verizon was not blocking port 80.  In 
one case I think it makes a great deal of sense.  The only thing I liked 
about having it on my boxen was that it was actually running on Hurd so 
it showed people that it isn't just vaporware.  I suppose that is a moot 
point though.


Thanks,

Barry

Gnumach Cleanup 13

[Barry deFreese]

Hi,

For kicks I did some more cleanup of warnings in gnumach.  The majority 
of the fixes are for "initialization of incompatible pointer.." errors.  
Here is a changelog:


2008-07-19  Barry deFreese  <[EMAIL PROTECTED]>

   * device/device_emul.h (struct device_emulation_ops): Takes 
mach_device_t not void *.
   * i386/i386at/autoconf.c: Make forward declarations for comintr() 
and lprintr() match prototype.
  + Add brackets around initialization members for bus_ctlr and 
bus_device structs.
   * i386/i386at/conf.c (struct dev_ops): Pass nomap instead of nulldev 
for map parameter.
   * i386/i386at/pic_isa.c: Add type for external function 
declarations. (Type defaults to int, make void).


Thanks,

Barry deFreese


Index: device/device_emul.h
===
RCS file: /sources/hurd/gnumach/device/Attic/device_emul.h,v
retrieving revision 1.1.2.1
diff -u -p -r1.1.2.1 device_emul.h
--- device/device_emul.h27 Mar 2007 22:47:09 -  1.1.2.1
+++ device/device_emul.h11 Nov 2008 02:05:02 -
@@ -32,9 +32,9 @@
 /* Each emulation layer provides these operations.  */
 struct device_emulation_ops
 {
-  void (*reference) (void *);
-  void (*dealloc) (void *);
-  ipc_port_t (*dev_to_port) (void *);
+  void (*reference) (mach_device_t);
+  void (*dealloc) (mach_device_t);
+  ipc_port_t (*dev_to_port) (mach_device_t);
   io_return_t (*open) (ipc_port_t, mach_msg_type_name_t,
   dev_mode_t, char *, device_t *);
   io_return_t (*close) (void *);
@@ -55,9 +55,9 @@ struct device_emulation_ops
   io_return_t (*map) (void *, vm_prot_t, vm_offset_t,
  vm_size_t, ipc_port_t *, boolean_t);
   void (*no_senders) (mach_no_senders_notification_t *);
-  io_return_t (*write_trap) (void *, dev_mode_t,
+  io_return_t (*write_trap) (mach_device_t, dev_mode_t,
 recnum_t, vm_offset_t, vm_size_t);
-  io_return_t (*writev_trap) (void *, dev_mode_t,
+  io_return_t (*writev_trap) (mach_device_t, dev_mode_t,
  recnum_t, io_buf_vec_t *, vm_size_t);
 };
 
Index: i386/i386at/autoconf.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/autoconf.c,v
retrieving revision 1.2.2.13
diff -u -p -r1.2.2.13 autoconf.c
--- i386/i386at/autoconf.c  9 Nov 2006 23:33:44 -   1.2.2.13
+++ i386/i386at/autoconf.c  11 Nov 2008 02:05:02 -
@@ -49,12 +49,12 @@
 
 #if NCOM > 0
 extern struct  bus_driver  comdriver;
-extern int comintr();
+extern voidcomintr();
 #endif /* NCOM */
 
 #if NLPR > 0
 extern struct  bus_driver  lprdriver;
-extern int lprintr();
+extern voidlprintr();
 #endif /* NLPR */
 
 struct bus_ctlrbus_master_init[] = {
@@ -62,7 +62,7 @@ structbus_ctlrbus_master_init[] = {
 /* drivername unit intraddresslen phys_address
  adaptor alive flags splpic */
 
-  0
+  {0}
 };
 
 
@@ -91,7 +91,7 @@ structbus_device  bus_device_init[] = {
 #endif /* NLPR > 0 */
 #endif /* MACH_LPR */
 
-  0
+  {0}
 };
 
 /*
Index: i386/i386at/conf.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/Attic/conf.c,v
retrieving revision 1.4.2.15
diff -u -p -r1.4.2.15 conf.c
--- i386/i386at/conf.c  1 Apr 2007 22:10:40 -   1.4.2.15
+++ i386/i386at/conf.c  11 Nov 2008 02:05:02 -
@@ -75,7 +75,7 @@ struct dev_opsdev_name_list[] =
   cninit() we stick something appropriate here through the
   indirect list */
{ "cn", nulldev,nulldev,nulldev,
- nulldev,  nulldev,nulldev,nulldev,
+ nulldev,  nulldev,nulldev,nomap,
  nodev,nulldev,nulldev,0,
  nodev },
 
Index: i386/i386at/pic_isa.c
===
RCS file: /sources/hurd/gnumach/i386/i386at/pic_isa.c,v
retrieving revision 1.1.1.1.4.2
diff -u -p -r1.1.1.1.4.2 pic_isa.c
--- i386/i386at/pic_isa.c   22 Jul 2008 22:28:07 -  1.1.1.1.4.2
+++ i386/i386at/pic_isa.c   11 Nov 2008 02:05:02 -
@@ -30,8 +30,8 @@
 
 
 /* These interrupts are always present */
-extern intnull(), fpintr(), hardclock(), kdintr();
-extern prtnull();
+extern void intnull(), fpintr(), hardclock(), kdintr();
+extern void prtnull();
 
 void (*ivect[NINTR])() = {
/* 00 */hardclock,  /* always */

Re: About merging the Hurd homepage and the Hurd wiki

[Barry deFreese]

Thomas Schwinge wrote:


To come to an end here, Barry, please select a port to use for the
-style URLS.  Then configure your
router for forwarding this port to 192.168.10.62, which is the IP of the
webserver-to-be, running on zenhost as a domU, and which is going to
replace the dedicated shitbox machine.

Speaking of zenhost, what can we do about the port 2260 forwarding
problem?  Try using a different port?  Is 2260 also documented as being
blocked by your ISP as well?  (You have received/read/undersigned the
terms and conditions, not me.)

I can do neither of these without your cooperation.


Regards,
 Thomas
  


Thomas,

OK, http://www.bddebian.com:/  should work. (Unfortunately I 
couldn't use 8080 either).  I can't find anything about 2260 being 
blocked.  Is there any chance that zenhost itself isn't liking something??


Thanks!

Barry

grub segfaulting

[Barry deFreese]

Hi folks,

I was playing with grub to see if I could find out where it is dying.  
It was working OK but now it is core dumping.  Even if I run the 
unmodified version I get segfaults with the following error on the console:


end_request: I/O error, dev 02:00, sector 0

Any clue on what could be causing that?

Thanks,

Barry

Re: grub segfaulting

[Barry deFreese]

Samuel Thibault wrote:

Barry deFreese, le Sun 31 May 2009 10:03:32 -0400, a écrit :
  

Even if I run the unmodified version I get segfaults with the
following error on the console:

end_request: I/O error, dev 02:00, sector 0

Any clue on what could be causing that?



Doesn't gdb give you a backtrace?

Samuel

  

Yes, sorry, I meant to post this yesterday.

#0 0x0804b520 in grub_memmove (to=0x12ae480, from=0x12b5200, len=4096)
at char_io.c:1298
d0 = 2752
d1 = 19617600
d2 = 19589568
#1 0x0804cdbc in rawread (drive=128, sector=68364, byte_offset=0,
byte_len=4096, buf=0x12ae480 "") at disk_io.c:281
sector_num = 68355
length = 19152896
num_sect = 54
track = 68355
size = 4096
bufaddr = 0x12b5200 ""
slen = 8
sectors_per_vtrack = 63
sector_size_bits = 
#2 0x0804e2ac in devread (sector=68364, byte_offset=0, byte_len=4096,
buf=0x12ae480 "") at disk_io.c:327
No locals.
#3 0x0804e5b5 in ext2_rdfsb (fsblock=1, buffer=)
at fsys_ext2fs.c:331
No locals.
#4 0x0804eb42 in ext2fs_dir (dirname=0x125ac61 "boot") at fsys_ext2fs.c:793
current_ino = 2
updir_ino = 2
str_chk = 18817012
linkbuf = 
"hs\026\001▒\215#\001\...@+\001Ⱥ*\001▒\215#\001g▒\000\000x9\002\000▒\205\037\001\001\000\000\000{r\026\001\000~\000\000\000~\000\000\000@+\001▒*\001▒\234\004\b\005\000\000\000\...@+\001\000~\000\000\005\000\000\0008▒*\001\005\000\000\000\000~\000\000\000~\000\000\200\000\000\000\005\000\000\0008▒*\001\211\235\004\b\005", 
'\0' , 
"9\016\006\0018y\006\001x▒*\001▒*\004\001\r\000\000\000\...@+\0014▒*\0018▒*\001\017▒\004\b4▒*\001\000\002\000\000\000@$\001\000\000\000\000\000\002\000\000\210▒*\001▒▒\004\b4▒*\001\...@+\001\000"...

link_count = 0
rest = 0x125ac65 ""
ch = 47 '/'
loc = 0
map = 
dp = 
#5 0x0804dab4 in grub_open (filename=0x125ac60 "/boot") at disk_io.c:1649
ptr = 0x 
tmp = 19578600
list_addr = 
#6 0x0805dfa3 in dump_func (arg=0x125ac59 "(hd0,1)/boot", flags=1)
at builtins.c:1245
to = 0x125ac72 "/tmp/grub_stage1"
fp = 
c = 
#7 0x0805e6ec in enter_cmdline (heap=0x125ac54 "dump (hd0,1)/boot", 
forever=1)

at cmdline.c:173
builtin = (struct builtin *) 0x80691b0
arg = 0x1 
#8 0x08057c4f in cmain () at stage2.c:1119
builtin = 
state = 195
prev_config_len = 8388608
prev_menu_len = -24968191
cmdline = 0x0
default_file = 
i = 
is_opened = 
#9 0x0804c2f0 in init_bios_info () at common.c:336
max_addr = 
cont = 
memtmp = 
addr = 19246164
drive = 129
#10 0x0804a5c3 in doit.5701 () at asmstub.c:141
env_for_exit = {{__jmpbuf = {-1, 19152904, 16928356, 16928152,
19578864, 134522260}, __mask_was_saved = 0, __saved_mask = 0}}
save_char = -1
serial_device = 0x0
serial_fd = -1
apm_bios_info = {version = 0, cseg = 0, offset = 0, cseg_16 = 0,
dseg_16 = 0, cseg_len = 0, cseg_16_len = 0, dseg_16_len = 0}
grub_scratch_mem = 0x1244000 ""
install_partition = 131072
linux_text_len = 0
ascii_key_map = {0 }
linux_data_tmp_addr = 0x0
console_current_color = 0
boot_drive = 0
device_map = (char **) 0x80769b8
io_map = {0 }
version_string = "0.97"
config_file = "/boot/grub/menu.lst", '\0' 
linux_data_real_addr = 0x0
bios_key_map = {0 }
disks = (struct geometry *) 0x80751b0
saved_entryno = 0


Thanks,

Barry

Re: plan to work on user-level device drivers

[Barry deFreese]

Da Zheng wrote:

Hi,

I am thinking about writing user-level device drivers. When I searched 
Internet, I found the paper "An Architecture for Device Drivers 
Executing as User-Level Tasks" written by David B. Golub, Guy G. 
Sotomayor and Freeman L. Rawson, III. It might be exactly what I want 
but unfortunately, the paper isn't available for downloading on 
Internet. I wonder if anyone knows the work and more importantly, 
where I can download the code.


My plan is to write a user-level device driver for testing and 
ideally, to port ddekit to Mach if it is possible.
The first device I choose will be ethernet card, which I think is the 
one I relatively familiar with.

Any suggestion is welcome!

Zheng Da




Zheng Da,

Yay!! Someone is finally tackling this!!  I have been looking at DDEKit, 
XNUs IOKit, and some others.  I don't know shite but if I can be of any 
help, let me know!


Barry

Re: blubber and grubber down

[Barry deFreese]

On 3/2/2010 8:48 AM, Thomas Schwinge wrote:
> Hello!
> 
> On Mon, Mar 01, 2010 at 11:09:35PM +0100, Ludovic Courtès wrote:
>> Thomas Schwinge  writes:
>>> But now grubber is re-installed, too.
>>
>> ‘goober’ and ‘clubber’ are down, too.
> 
> OK, but I can't do anything about these: I can only manage those that are
> domUs on zenhost,
> .
> 
> Barry?
> 
> 
> Regards,
>  Thomas

I'll check on goober.  Clubber seems to keep rebooting on startup.  Not sure if 
it is a grub issue
or kernel issue. :(

Barry

Re: Account request

[Barry deFreese]

On 5/9/2011 1:09 PM, Thomas Schwinge wrote:
> Hallo Steven!
> 
> On Mon, 9 May 2011 12:59:27 -0400, seth seth  wrote:
>> Thanks for creating the account but unable to login, is
>> flubber.bddebian.comdown?
> 
> His whole network is unreachable at the moment.  I've already informed
> Barry; he's going to have a look.
> 
> 
> Grüße,
>  Thomas

Should be back up now.  Please let me know if there is still an issue.

Thanks,

Barry

Re: netdde not detecting cards

[Barry deFreese]

On 7/6/2012 12:10 AM, Samuel Thibault wrote:
> Hello,
> 
> To people who were having problems of network card detection with
> netdde, I've found that it was hardcoded that only bus 0 and 2 were
> probed for.  The attached patch should probe for all buses, and
> probably fix the issue you were having. Check your lspci output, if it
> looked like
> 
> 03:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network
> Connection (rev 04)
> 
> i.e. first number for the network board is neither 00 nor 02, then
> it's normal that netdde was not finding your card. You can apply the
> attached patch to the hurd package, install it, and rebuild netdde, or
> just wait for the next hurd+netdde upload, or CD image build.
> 
> Samuel
> 

Rockin', I will see if I can try this tonight.  Thanks Samuel!!

Barry

Strange output of gcc -E on GNU/Hurd

[Barry deFreese]

Hi folks,

In looking at libprelude it generates a lot of files using gawk.  The attached 
file is generated
from gawk and then is run through gcc -E.

On GNU/Hurd, I get significantly different results than I do from GNU/Linux.  
Anyone have a clue why
that might be or where I would look to "debug" this?

Thanks!

Barry deFreese

/* Output of mkerrcodes.awk.  DO NOT EDIT.  */

/* errnos.h - List of system error values.
   Copyright (C) 2003, 2004 g10 Code GmbH

   This file is part of libgpg-error.

   libgpg-error is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public License
   as published by the Free Software Foundation; either version 2.1 of
   the License, or (at your option) any later version.
 
   libgpg-error is distributed in the hope that it will be useful, but
   WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.
 
   You should have received a copy of the GNU Lesser General Public
   License along with libgpg-error; if not, write to the Free
   Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
   02111-1307, USA.  */



#include 

#ifdef E2BIG
E2BIG   PRELUDE_ERROR_E2BIG
#endif
#ifdef EACCES
EACCES  PRELUDE_ERROR_EACCES
#endif
#ifdef EADDRINUSE
EADDRINUSE  PRELUDE_ERROR_EADDRINUSE
#endif
#ifdef EADDRNOTAVAIL
EADDRNOTAVAIL   PRELUDE_ERROR_EADDRNOTAVAIL
#endif
#ifdef EADV
EADVPRELUDE_ERROR_EADV
#endif
#ifdef EAFNOSUPPORT
EAFNOSUPPORTPRELUDE_ERROR_EAFNOSUPPORT
#endif
#ifdef EAGAIN
EAGAIN  PRELUDE_ERROR_EAGAIN
#endif
#ifdef EALREADY
EALREADYPRELUDE_ERROR_EALREADY
#endif
#ifdef EAUTH
EAUTH   PRELUDE_ERROR_EAUTH
#endif
#ifdef EBACKGROUND
EBACKGROUND PRELUDE_ERROR_EBACKGROUND
#endif
#ifdef EBADE
EBADE   PRELUDE_ERROR_EBADE
#endif
#ifdef EBADF
EBADF   PRELUDE_ERROR_EBADF
#endif
#ifdef EBADFD
EBADFD  PRELUDE_ERROR_EBADFD
#endif
#ifdef EBADMSG
EBADMSG PRELUDE_ERROR_EBADMSG
#endif
#ifdef EBADR
EBADR   PRELUDE_ERROR_EBADR
#endif
#ifdef EBADRPC
EBADRPC PRELUDE_ERROR_EBADRPC
#endif
#ifdef EBADRQC
EBADRQC PRELUDE_ERROR_EBADRQC
#endif
#ifdef EBADSLT
EBADSLT PRELUDE_ERROR_EBADSLT
#endif
#ifdef EBFONT
EBFONT  PRELUDE_ERROR_EBFONT
#endif
#ifdef EBUSY
EBUSY   PRELUDE_ERROR_EBUSY
#endif
#ifdef ECANCELED
ECANCELED   PRELUDE_ERROR_ECANCELED
#endif
#ifdef ECHILD
ECHILD  PRELUDE_ERROR_ECHILD
#endif
#ifdef ECHRNG
ECHRNG  PRELUDE_ERROR_ECHRNG
#endif
#ifdef ECOMM
ECOMM   PRELUDE_ERROR_ECOMM
#endif
#ifdef ECONNABORTED
ECONNABORTEDPRELUDE_ERROR_ECONNABORTED
#endif
#ifdef ECONNREFUSED
ECONNREFUSEDPRELUDE_ERROR_ECONNREFUSED
#endif
#ifdef ECONNRESET
ECONNRESET  PRELUDE_ERROR_ECONNRESET
#endif
#ifdef ED
ED  PRELUDE_ERROR_ED
#endif
#ifdef EDEADLK
EDEADLK PRELUDE_ERROR_EDEADLK
#endif
#ifdef EDEADLOCK
EDEADLOCK   PRELUDE_ERROR_EDEADLOCK
#endif
#ifdef EDESTADDRREQ
EDESTADDRREQPRELUDE_ERROR_EDESTADDRREQ
#endif
#ifdef EDIED
EDIED   PRELUDE_ERROR_EDIED
#endif
#ifdef EDOM
EDOMPRELUDE_ERROR_EDOM
#endif
#ifdef EDOTDOT
EDOTDOT PRELUDE_ERROR_EDOTDOT
#endif
#ifdef EDQUOT
EDQUOT  PRELUDE_ERROR_EDQUOT
#endif
#ifdef EEXIST
EEXIST  PRELUDE_ERROR_EEXIST
#endif
#ifdef EFAULT
EFAULT  PRELUDE_ERROR_EFAULT
#endif
#ifdef EFBIG
EFBIG   PRELUDE_ERROR_EFBIG
#endif
#ifdef EFTYPE
EFTYPE  PRELUDE_ERROR_EFTYPE
#endif
#ifdef EGRATUITOUS
EGRATUITOUS PRELUDE_ERROR_EGRATUITOUS
#endif
#ifdef EGREGIOUS
EGREGIOUS   PRELUDE_ERROR_EGREGIOUS
#endif
#ifdef EHOSTDOWN
EHOSTDOWN   PRELUDE_ERROR_EHOSTDOWN
#endif
#ifdef EHOSTUNREACH
EHOSTUNREACHPRELUDE_ERROR_EHOSTUNREACH
#endif
#ifdef EIDRM
EIDRM   PRELUDE_ERROR_EIDRM
#endif
#ifdef EIEIO
EIEIO   PRELUDE_ERROR_EIEIO
#endif
#ifdef EILSEQ
EILSEQ  PRELUDE_ERROR_EILSEQ
#endif
#ifdef EINPROGRESS
EINPROGRESS PRELUDE_ERROR_EINPROGRESS
#endif
#ifdef EINTR
EINTR   PRELUDE_ERROR_EINTR
#endif
#ifdef EINVAL
EINVAL  PRELUDE_ERROR_EINVAL
#endif
#ifdef EIO
EIO PRELUDE_ERROR_EIO
#endif
#ifdef EISCONN
EISCONN PRELUDE_ERROR_EISCONN
#endif
#ifdef EISDIR
EISDIR  PRELUDE_ERROR_EISDIR
#endif
#ifdef EISNAM
EISNAM  PRELUDE_ERROR_EISNAM
#endif
#ifdef EL2HLT
EL2HLT  PRELUDE_ERROR_EL2HLT
#endif
#ifdef EL2NSYNC
EL2NSYNCPRELUDE_ERROR_EL2NSYNC
#endif
#ifdef EL3HLT
EL3HLT  PRELUDE_ERROR_EL3HLT
#endif
#ifdef EL3RST
EL3RST  PRELUDE_ERROR_EL3RST
#endif
#ifdef ELIBACC
ELIBACC PRELUDE_ERROR_ELIBACC
#endif
#ifdef ELIBBAD
ELIBBAD PRELUDE_ERROR_ELIBBAD
#endif
#ifdef ELIBEXEC
ELIBEXECPRELUDE_ERROR_ELIBEXEC
#endif
#ifdef ELIBMAX
ELIBMAX PRELUDE_ERROR_ELIBMAX
#endif
#ifdef ELIBSCN
ELIBSCN PRELUDE_ERROR_ELIBSCN
#endif
#ifdef ELNRNG
ELNRNG  PRELUDE_ERROR_ELNRNG
#endif
#ifdef ELOOP
ELOOP   PRELUDE_ERROR_ELOOP
#endif
#ifdef EMEDIUMTYPE
EMEDIUMTYPE PRELUDE_ERROR_EMEDIUMTYPE
#endif
#ifdef EMFILE
EMFILE  PRELUDE_ERROR_EMFILE
#endif
#ifdef EMLINK
EMLINK  PRELUDE_ERROR_EMLINK
#endif
#ifdef EMSGSIZE
EMSGSIZEPRELUDE_ERROR_EMSGSIZE
#endif
#ifdef EMULTIHOP

Re: Strange output of gcc -E on GNU/Hurd

[Barry deFreese]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/16/2012 3:43 AM, Thomas Schwinge wrote:
> Hi!
> 
> On Sun, 15 Jul 2012 16:32:06 -0400, Barry deFreese  
> wrote:
>> In looking at libprelude it generates a lot of files using gawk.  The 
>> attached file is
>> generated from gawk and then is run through gcc -E.
>> 
>> On GNU/Hurd, I get significantly different results than I do from GNU/Linux. 
>>  Anyone have a
>> clue why that might be or where I would look to "debug" this?
> 
> What errors do you get?
> 
> 
> Grüße, Thomas
> 
Thomas,

I'm not getting any errors it is just that the output is so radically different 
that the package
that processes the output files is having problems.

Attached is foo.h processed by both hurd and linux.

Thanks,

Barry



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAEJFcACgkQ5ItltUs5T34pgQCeLut92VjadzC52/NhPwHM/glA
yHoAoPVZ161+tcOqRXGUiVcjutWXv4u1
=ytC2
-END PGP SIGNATURE-

# 1 "foo.h"
# 1 ""
# 1 "foo.h"
# 25 "foo.h"
# 1 "/usr/include/errno.h" 1 3 4
# 29 "/usr/include/errno.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 323 "/usr/include/features.h" 3 4
# 1 "/usr/include/i386-gnu/bits/predefs.h" 1 3 4
# 324 "/usr/include/features.h" 2 3 4
# 356 "/usr/include/features.h" 3 4
# 1 "/usr/include/i386-gnu/sys/cdefs.h" 1 3 4
# 359 "/usr/include/i386-gnu/sys/cdefs.h" 3 4
# 1 "/usr/include/i386-gnu/bits/wordsize.h" 1 3 4
# 360 "/usr/include/i386-gnu/sys/cdefs.h" 2 3 4
# 357 "/usr/include/features.h" 2 3 4
# 388 "/usr/include/features.h" 3 4
# 1 "/usr/include/i386-gnu/gnu/stubs.h" 1 3 4



# 1 "/usr/include/i386-gnu/bits/wordsize.h" 1 3 4
# 5 "/usr/include/i386-gnu/gnu/stubs.h" 2 3 4


# 1 "/usr/include/i386-gnu/gnu/stubs-32.h" 1 3 4
# 8 "/usr/include/i386-gnu/gnu/stubs.h" 2 3 4
# 389 "/usr/include/features.h" 2 3 4
# 30 "/usr/include/errno.h" 2 3 4






# 1 "/usr/include/i386-gnu/bits/errno.h" 1 3 4
# 10 "/usr/include/i386-gnu/bits/errno.h" 3 4
enum __error_t_codes
{


 EPERM = ((0x10 << 26) | ((1) & 0x3fff)),

 ENOENT = ((0x10 << 26) | ((2) & 0x3fff)),

 ESRCH = ((0x10 << 26) | ((3) & 0x3fff)),

 EINTR = ((0x10 << 26) | ((4) & 0x3fff)),

 EIO = ((0x10 << 26) | ((5) & 0x3fff)),

 ENXIO = ((0x10 << 26) | ((6) & 0x3fff)),

 E2BIG = ((0x10 << 26) | ((7) & 0x3fff)),

 ENOEXEC = ((0x10 << 26) | ((8) & 0x3fff)),

 EBADF = ((0x10 << 26) | ((9) & 0x3fff)),

 ECHILD = ((0x10 << 26) | ((10) & 0x3fff)),

 EDEADLK = ((0x10 << 26) | ((11) & 0x3fff)),

 ENOMEM = ((0x10 << 26) | ((12) & 0x3fff)),

 EACCES = ((0x10 << 26) | ((13) & 0x3fff)),

 EFAULT = ((0x10 << 26) | ((14) & 0x3fff)),

 ENOTBLK = ((0x10 << 26) | ((15) & 0x3fff)),

 EBUSY = ((0x10 << 26) | ((16) & 0x3fff)),

 EEXIST = ((0x10 << 26) | ((17) & 0x3fff)),

 EXDEV = ((0x10 << 26) | ((18) & 0x3fff)),

 ENODEV = ((0x10 << 26) | ((19) & 0x3fff)),

 ENOTDIR = ((0x10 << 26) | ((20) & 0x3fff)),

 EISDIR = ((0x10 << 26) | ((21) & 0x3fff)),

 EINVAL = ((0x10 << 26) | ((22) & 0x3fff)),

 EMFILE = ((0x10 << 26) | ((24) & 0x3fff)),

 ENFILE = ((0x10 << 26) | ((23) & 0x3fff)),

 ENOTTY = ((0x10 << 26) | ((25) & 0x3fff)),

 ETXTBSY = ((0x10 << 26) | ((26) & 0x3fff)),

 EFBIG = ((0x10 << 26) | ((27) & 0x3fff)),

 ENOSPC = ((0x10 << 26) | ((28) & 0x3fff)),

 ESPIPE = ((0x10 << 26) | ((29) & 0x3fff)),

 EROFS = ((0x10 << 26) | ((30) & 0x3fff)),

 EMLINK = ((0x10 << 26) | ((31) & 0x3fff)),

 EPIPE = ((0x10 << 26) | ((32) & 0x3fff)),

 EDOM = ((0x10 << 26) | ((33) & 0x3fff)),

 ERANGE = ((0x10 << 26) | ((34) & 0x3fff)),

 EAGAIN = ((0x10 << 26) | ((35) & 0x3fff)),


 EINPROGRESS = ((0x10 << 26) | ((36) & 0x3fff)),

 EALREADY = ((0x10 << 26) | ((37) & 0x3fff)),

 ENOTSOCK = ((0x10 << 26) | ((38) & 0x3fff)),

 EMSGSIZE = ((0x10 << 26) | ((40) & 0x3fff)),

 EPROTOTYPE = ((0x10 << 26) | ((41) & 0x3fff)),

 ENOPROTOOPT = ((0x10 << 26) | ((42) & 0x3fff)),

 EPROTONOSUPPORT = ((0x10 << 26) | ((43) & 0x3fff)),

 ESOCKTNOSUPPORT = ((0x10 << 26) | ((44) & 0x3fff)),

 EOPNOTSUPP = ((0x10 << 26) | ((45) & 0x3fff)),

 EPFNOSUPPORT = ((0x10 << 26) | ((46) & 0x3fff)),

 EAFNOSUPPORT = ((0x10 << 26) | ((47) & 0x3fff)),

 EADDRINUSE = ((0x10 << 26) | ((48) &

Re: Concerning pthreads and such

[Barry deFreese]

On 6/20/2012 2:04 PM, Thomas Thomas wrote:
> Let me try this again:
> 
> I am sending this to GNU and not debian because:
> 1) There are several debian people who subscribe to GNU also,
> 2) The debian development list for Hurd doesn't accept attachments this large,
> and 3) debian seems to be one of the most used distributions for Hurd.
> 
> This is a patch to hurd-20120605-2 to have it use pthreads instead of 
> cthreads.
> It does have some issues. It still needs a libpthread directory in the hurd 
> source
> tree (I believe that all the directory needs in it is links to the .so and .a 
> files).
> Libpthread needs to have the function provided by cancel-cond.c in it (so you
> need to rebuild libpthread, part of glibc: probably all of glibc then).
> [hurd_condition_wait allows RPCs to be interrupted with hurd_thread_cancel]
> 
> Also included is a patch to netdde, which also needs to be rebuild if one 
> wants
> to have working networking.
> 
> As always, I thank Barry DeFreese and Vicente Ara for doing most of the work.
> 
> Thomas DiModica
> 
> PS. What would be, in everyone's opinion, a rigorous test (or tests) that the
> pthreads code works?
> 
Thomas,

Have you gotten any feedback on this?  Are you still working on it/testing it?  
Great stuff!

Barry

Re: Concerning pthreads and such

[Barry deFreese]

On 7/19/2012 6:55 PM, Thomas Thomas wrote:
> From: Thomas Schwinge 
> Sent: Thursday, July 19, 2012 12:24 AM
> Subject: Re: Concerning pthreads and such
> 
>> If you do already know a bit or two about Git and promise to be
>> sufficiently careful, then I'd like to add you to the Savannah Hurd
>> group, so that you can directly push to the Savannah hurd/hurd.git
>> repository.
> 
> Thanks... but I don't really feel confident about my abilities with git.
> I tried pushing everything to my bitbucket account:
> Web interface: https://bitbucket.org/timmytdm/pthreads-hurd
> Git: https://bitbucket.org/timmytdm/pthreads-hurd.git
> 
> Am I doing things right?
> 
> Thomas D
> 
> 
> 
Thomas,

So far so good.  I see you've renamed hurd_condition_wait in most places but 
did you move the actual
definition as well?  I am getting undefined references to hurd_cond_wait.

Thanks!

Barry

Re: Warnings about error_t in glibc on GNU/Hurd

[Barry deFreese]

How about ENOERR?? :)  Sorry, couldn't resist.

BTW, Thomas has a listing of several of the errors/warnings listed here:
http://www.gnu.org/software/hurd/open_issues/glibc.html#index1h1

I'm certainly fine with just adding a value for 0.

Thanks for taking the time to reply.

Barry

On 7/23/2012 3:51 PM, Roland McGrath wrote:
> Grepping for 'case 0:' shows exactly 8 places where this warning
> should arise.  One of those is the __hurd_fail inline in hurd.h, so
> that one instance probably generates the warning in many
> compilations.
> 
> Most of these are switches with only a few cases where it would be
> easy to just change them to use 'if' instead of 'switch' without
> complicating the code.  Doing that would just avoid the question.
> 
> I'm not real sure about giving an E* name to 0, since E* names are
> for error codes, and 0 isn't one.  But OTOH for error_t 0 is
> certainly one of the expected values, so it makes sense to have an
> enum constant for it.  The question is what name to use, and then
> whether to actually use that name or just add it to suppress the
> warning while still using 0 in the code.
> 
> I tried GCC 4.4, and it doesn't give this warning when you use an
> integer literal as long as the enum has some name for that integer
> value.  If other GCC versions do warn for 'case 0:' when some item
> 'foo = 0' is in the enum, someone please tell me.
> 
> Assuming the warning behavior is consistent with what I've seen, my
> inclination is not to change the code to use a symbolic name for
> this.  That's mostly because the obvious choices like ESUCCESS or
> EOK just seem wrong to me since the E* name space ought to be for
> actual error codes, and I can't think of a good name I'd actually
> want to be writing in the code.  So I'm inclined to pick some name
> that is not very friendly to use (i.e. long and verbose), perhaps
> even in the _* space, and add that to the error_t enum just for the
> purpose of suppressing these warnings and not expect people to use
> it in the code.
> 
> 
> Thanks,
> Roland
> 
> 

Hurd build system Makeconf

[Barry deFreese]

Hi folks,

I applied Thomas Thomas's pthreads stuff to the debian package source and am 
trying to build.  I am
trying to use glibc's libpthread.  So I get the following error(s):

make: *** No rule to make target `libpthread', needed by `libiohelp'.  Stop.

I am thinking that this line in Makeconf is the issue:

# More useful version of HURDLIBS
library_deps=$(foreach lib,$(HURDLIBS),$(..)lib$(lib)/lib$(lib).so)

I can't see anyway there that it would use libpthread from /usr/lib/...  Now of 
course we don't
usually want to use /usr/lib/... because it would pick up the currently 
installed libs instead of
the built ones but we need to make exceptions.  Do you think we should have a 
section like OTHERLIBS
or something?  Or should pthreads be removed from HURDLIBS and use -lpthread?

Thanks!

Barry

Re: Hurd build system Makeconf

[Barry deFreese]

On 7/24/2012 10:26 PM, Roland McGrath wrote:
> HURDLIBS is for things that are built in that source tree.  If you're using
> a library that comes from the libc install or someplace like that, then
> -lfoo is the right way to use it.
> 
> 
That is what I thought, thanks Roland.  It seems to work.

Now the question is, what to do with cancel-cond.c?  I'm thinking of just 
sticking it in
libshouldbeinlibc for now?  Is there a more appropriate place?

Thanks again,

Barry

Re: Hurd build system Makeconf

[Barry deFreese]

On 7/25/2012 4:48 AM, Richard Braun wrote:
> On Tue, Jul 24, 2012 at 11:12:11PM -0400, Barry deFreese wrote:
>> Now the question is, what to do with cancel-cond.c?  I'm thinking of just 
>> sticking it in
>> libshouldbeinlibc for now?  Is there a more appropriate place?
> 
> Why not in libpthread, near the pthread_cond_wait and
> pthread_cond_timedwait functions, considering how related they are ?
> 
Richard,

Mainly because there is no libpthread in hurd sources any more... :)

Barry

Re: hurd with libpthread

[Barry deFreese]

w000t!!  Finally, nice job folks!!

(Sorry to have disappeared again... :-()

Barry

On 11/27/2012 9:54 PM, Samuel Thibault wrote:
> Hello,
> 
> At last that work is out!
> 
> I've pushed the patchqueue from Richard to upstreams, built test debian
> packages on 
> 
> deb http://people.debian.org/~sthibault/hurd-i386/tmp ./
> 
> I hope to have not forgotten anything for the dependencies: the new hurd
> depends on the new libc0.3, and breaks the old netdde. I can confirm
> that the upgrade went fine on my machine, but it might be useful to test
> other cases.
> 
> We'll have to wait for eglibc 2.13-38 to get uploaded to unstable before
> being able to upload that to unstable, and eventually push that to
> buildds, etc.
> 
> I have to thank a lot everybody who was involved into that big change.
> 
> Samuel
> 
> 

Re: is the new

[Barry deFreese]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry guys, life has really gotten in the way for the last few months and 
probably for another
year or so... :(

Barry

On 3/6/2013 5:38 PM, Thomas Schwinge wrote:
> Hi!
> 
> As Barry's zenhost, the Xen dom0 that is, or rather was, hosting, amongst 
> others, snubber, the
> machine behind , has now been down for more 
> than half a year
> already, with no immediate hope of getting it back in service, and Richard, 
> on the other hand,
> has been more than willing to begin hosting, on his darnassus machine, a new 
> instance of our
> web pages/wiki conglomerate, we have then been working, again already a month 
> ago..., on
> setting that up, and now I finally got around to finishing this transition.
>  has been updated, and 
>  in particular 
> again tells a true
> story about how to work on the pages.  In short, 
>  is the
> new .
> 
> 
> Grüße, Thomas
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlE36tEACgkQ5ItltUs5T365wgCfUT76sFnVzGgPR73hHWllFBQ/
I/MAoJb3iavynv4K/Pqtz4oS+knMbrW0
=OMYT
-END PGP SIGNATURE-

Re: cthreads -> pthreads FOSS Factory project

[Barry deFreese]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/19/2013 11:05 AM, Thomas Schwinge wrote:
> Hi!
> 
> On Sat, 16 Mar 2013 18:33:28 +, Pino Toscano  
> wrote:
>> commit 5d0f6782028c754b2c0a5721d14b8c76b47d31db Author: Pino Toscano
>>  Date:   Sat Mar 16 18:59:24 2013 +0100
>> 
>> drop the pthread conversion project
>> 
>> it has been done recently
> 
> I've scheduled for deletion (on Sat March 23, 11:00 EDT) the corresponding 
> FOSS Factory
> project, .  As it just had a bounty 
> of 40.32 EUR, but
> several people had been contributing to it, spread over several years, my 
> proposal is to just
> feed that amount back into the general GNU Hurd pool, which is what will 
> happen on Saturday
> unless someone intervenes.
> 
> 
> Grüße, Thomas
> 

"I want my $2.00!!"  Sorry, American movie quote..  I say works for me.. :)

Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFIgtEACgkQ5ItltUs5T36idACggGlldTuAV8JcFyiVXswQs5Jc
SDEAoNQvwX2nKG9nJgLEt963t/iFL2rs
=Sm4d
-END PGP SIGNATURE-

RFC for patch to add task_{set,get}_name RPC

[Barry deFreese]

Hi folks,

I am trying to get a test environment going to test this but in the meantime if 
any of you care to
review, here is a patch to add task_set_name() and task_get_name() RPCs to 
gnumach.

Thanks!

Barry

diff --git a/include/mach/gnumach.defs b/include/mach/gnumach.defs
index 7331334..b26be96 100644
--- a/include/mach/gnumach.defs
+++ b/include/mach/gnumach.defs
@@ -37,3 +37,17 @@ type vm_cache_statistics_data_t = struct[11] of integer_t;
 routine vm_cache_statistics(
target_task : vm_task_t;
out vm_cache_stats  : vm_cache_statistics_data_t);
+
+/*
+ *  Set the name of a task.
+ */
+routine task_set_name(
+   task: task_t;
+   name: task_name_t);
+
+/*
+ *  Get the name of a task.
+ */
+routine task_get_name(
+   task: task_t;
+   out name: task_name_t);
diff --git a/include/mach/mach_types.defs b/include/mach/mach_types.defs
index 607d5d9..c913cbb 100644
--- a/include/mach/mach_types.defs
+++ b/include/mach/mach_types.defs
@@ -230,6 +230,8 @@ type emulation_vector_t = ^array[] of 
vm_offset_t;
 
 type rpc_signature_info_t  = array[*:1024] of int;
 
+type task_name_t   = (MACH_MSG_TYPE_STRING, 8*32);
+
 #ifKERNEL_SERVER
 simport ;  /* for null conversion */
 simport ;   /* for task/thread conversion */
diff --git a/include/mach/mach_types.h b/include/mach/mach_types.h
index 8768482..5bb3a7b 100644
--- a/include/mach/mach_types.h
+++ b/include/mach/mach_types.h
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/mach/task_name.h b/include/mach/task_name.h
new file mode 100644
index 000..296bd9e
--- /dev/null
+++ b/include/mach/task_name.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2013 Free Software Foundation, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ *  Author: Barry deFreese.
+ */
+
+#ifndef _TASK_NAME_H_
+#define _TASK_NAME_H_
+
+typedef char task_name_t[32];
+
+#endif /* _TASK_NAME_H_ */
diff --git a/kern/task.c b/kern/task.c
index 114dd31..d8690c6 100644
--- a/kern/task.c
+++ b/kern/task.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1212,3 +1213,33 @@ task_ras_control(
 #endif
 return ret;
 }
+
+kern_return_t
+task_set_name (
+   task_t task,
+   task_name_t name)
+{
+
+   if (task == TASK_NULL)
+   return KERN_INVALID_ARGUMENT;
+
+   strncpy(task->name, name, sizeof(task->name) -1);
+   task->name[sizeof(task->name) -1] = '\0';
+
+   return KERN_SUCCESS;
+}
+
+kern_return_t 
+task_get_name (
+   task_t task, 
+   task_name_t name)
+{
+
+   if (task == TASK_NULL)
+   return KERN_INVALID_ARGUMENT;
+
+   strncpy(name, task->name, sizeof(task->name) - 1);
+   name[sizeof(name) -1] = '\0';
+
+   return KERN_SUCCESS;
+}
diff --git a/kern/task.h b/kern/task.h
index 9bfea57..842979a 100644
--- a/kern/task.h
+++ b/kern/task.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -111,6 +112,8 @@ struct task {
natural_t   cow_faults; /* copy-on-write faults counter */
natural_t   messages_sent;  /* messages sent counter */
natural_t   messages_received; /* messages received counter */
+
+   task_name_t name;   /* Task name */
 };
 
 #define task_lock(task)simple_lock(&(task)->lock)

Re: RFC for patch to add task_{set,get}_name RPC

[Barry deFreese]

Gentlemen,

I don't want to get into the political or technical merits but here is an 
updated patch that works.

I will let you decide what to do with it. :)

Thanks,

Barry


diff --git a/include/mach/gnumach.defs b/include/mach/gnumach.defs
index 7331334..b26be96 100644
--- a/include/mach/gnumach.defs
+++ b/include/mach/gnumach.defs
@@ -37,3 +37,17 @@ type vm_cache_statistics_data_t = struct[11] of integer_t;
 routine vm_cache_statistics(
target_task : vm_task_t;
out vm_cache_stats  : vm_cache_statistics_data_t);
+
+/*
+ *  Set the name of a task.
+ */
+routine task_set_name(
+   task: task_t;
+   name: task_name_t);
+
+/*
+ *  Get the name of a task.
+ */
+routine task_get_name(
+   task: task_t;
+   out name: task_name_t);
diff --git a/include/mach/mach_types.defs b/include/mach/mach_types.defs
index 607d5d9..c913cbb 100644
--- a/include/mach/mach_types.defs
+++ b/include/mach/mach_types.defs
@@ -230,6 +230,8 @@ type emulation_vector_t = ^array[] of 
vm_offset_t;
 
 type rpc_signature_info_t  = array[*:1024] of int;
 
+type task_name_t   = (MACH_MSG_TYPE_STRING, 8*32);
+
 #ifKERNEL_SERVER
 simport ;  /* for null conversion */
 simport ;   /* for task/thread conversion */
diff --git a/include/mach/mach_types.h b/include/mach/mach_types.h
index 8768482..5bb3a7b 100644
--- a/include/mach/mach_types.h
+++ b/include/mach/mach_types.h
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/mach/task_name.h b/include/mach/task_name.h
new file mode 100644
index 000..d6306e2
--- /dev/null
+++ b/include/mach/task_name.h
@@ -0,0 +1,28 @@
+/*
+ * Copyright (C) 2013 Free Software Foundation, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ *  Author: Barry deFreese.
+ */
+
+#ifndef _TASK_NAME_H_
+#define _TASK_NAME_H_
+
+#define TASK_NAME_SIZE 32
+
+typedef char task_name_t[TASK_NAME_SIZE];
+
+#endif /* _TASK_NAME_H_ */
diff --git a/kern/task.c b/kern/task.c
index 114dd31..438037b 100644
--- a/kern/task.c
+++ b/kern/task.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1212,3 +1213,33 @@ task_ras_control(
 #endif
 return ret;
 }
+
+kern_return_t
+task_set_name (
+   task_t task,
+   task_name_t name)
+{
+
+   if (task == TASK_NULL)
+   return KERN_INVALID_ARGUMENT;
+
+   strncpy(task->name, name, TASK_NAME_SIZE - 1);
+   task->name[TASK_NAME_SIZE - 1] = '\0';
+
+   return KERN_SUCCESS;
+}
+
+kern_return_t 
+task_get_name (
+   task_t task, 
+   task_name_t name)
+{
+
+   if (task == TASK_NULL)
+   return KERN_INVALID_ARGUMENT;
+
+   strncpy(name, task->name, TASK_NAME_SIZE - 1);
+   name[TASK_NAME_SIZE - 1] = '\0';
+
+   return KERN_SUCCESS;
+}
diff --git a/kern/task.h b/kern/task.h
index 9bfea57..842979a 100644
--- a/kern/task.h
+++ b/kern/task.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -111,6 +112,8 @@ struct task {
natural_t   cow_faults; /* copy-on-write faults counter */
natural_t   messages_sent;  /* messages sent counter */
natural_t   messages_received; /* messages received counter */
+
+   task_name_t name;   /* Task name */
 };
 
 #define task_lock(task)simple_lock(&(task)->lock)

Re: Debian GNU/Hurd 2013 released!

[Barry deFreese]

On 5/21/2013 7:24 PM, Samuel Thibault wrote:
> This is now published on
> 
> http://www.debian.org/ports/hurd/hurd-news.en.html
> http://www.gnu.org/software/hurd/news/2013-05-debian_gnu_hurd_2013.html
> 
> Please spread the news :)
> 
> Samuel
> 
> 
\o/  Nice work folks!!

Barry

RFC - GNU System Distribution

[Barry deFreese]

Hello,

For several weeks now I have been considering creating an Ubuntu-based
GNU/Hurd distribution. After bouncing it off of a few people it appears
that most are against it and would rather push to get the GNU System going.

Along those lines we have been having some discussions on #hug and
##hurd and have laid out some VERY preliminary ideas/thoughts on the
following wiki page:  http://hurd.gnufans.org/bin/view/Distrib/GnuOS

I have a few concerns personally but if this is the direction the
community would rather take, then I am willing to jump in (though hesitant).

Please have a look at the wiki, let's get some discussion going, set
some direction and lets get it going.

I apologize for the cross-post to bug-hurd but I know that there are
people that are not subscribed to this list and I personally want this
to be true community driven agenda.

What say you?

Thanks,

Barry deFreese (aka bddebian)


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

Re: RFC - GNU System Distribution

[Barry deFreese]

- Original Message - 
From: "Richard M. Stallman" <[EMAIL PROTECTED]>

To: "John Williams" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; ; 
Sent: Friday, July 29, 2005 9:54 AM
Subject: Re: RFC - GNU System Distribution



 They will have no clue that it is an OS unless we are VERY
   explicit in calling it an OS.  So we should refer to is as "the GNU
   operating system".

Sure, there's no problem with saying "operating system" to help
clarify things.



This is all I have been saying all along, sheesh...  Thank you. :-)

Barry deFreese (aka bddebian) 




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

Re: Checking out /gnumach exits with error, cause 'aux' reserved on cvsnt

[Barry deFreese]

- Original Message - 
From: "Ashish Gokhale" <[EMAIL PROTECTED]>

To: "BUG Hurd" 
Sent: Wednesday, February 15, 2006 3:39 PM
Subject: Re: Checking out /gnumach exits with error,cause 'aux' reserved on 
cvsnt




Hi Thomas,
I get error "cvs server: cannot find module
`gnumach-1-branch' - ignored".

I am trying "cvs -d
:pserver:[EMAIL PROTECTED]:/sources/hurd
co gnumach-1-branch". Is the server URL correct???

yet I dont have a linux or debian box available, is
there any way i could down load latest GnuMach code
(and the branch as well) on my windows desktop?

Thanks
- Ashish
--- Thomas Schwinge <[EMAIL PROTECTED]> wrote:


On Mon, Feb 06, 2006 at 09:59:08PM +0100, Samuel
Thibault wrote:
> Ashish Gokhale, le Sun 05 Feb 2006 19:07:17 +,
a ?crit :
> > I checked for the error message "cvs [checkout
> > aborted]: could not chdir to gnumach/i386/aux:
Invalid
> > argument"
> > I am using windows2000 to download & study the
GnuMach
> > source code. It seems 'aux' is a reserved word &
its
>
> Ah... Welcome to windows' silly
backward-compatibility: just try, you
> won't be able to create files names con, com1,
aux, prn, etc. You should
> probably get source from a linux box and copy it
to your windows box
> *after* having renamed the aux directory.

... or just get the `gnumach-1-branch', which
doesn't have a directory
called `aux', which is being actually used compared
to HEAD, and which is
what I suggested before, if I recall correctly.


Regards,
 Thomas





Egads, why would you want to bring to Windows?  Anyway, what you want is:

cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/hurd co -r 
gnumach-1-branch gnumach


Enjoy,

Barry deFreese (aka bddebian) 




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

Re: Remove GNU Mach's unused device drivers

[Barry deFreese]

- Original Message - 
From: "Thomas Bushnell BSG" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Cc: ; <[EMAIL PROTECTED]>
Sent: Saturday, February 18, 2006 7:47 PM
Subject: Re: Remove GNU Mach's unused device drivers



"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes:


   If a driver is redundant, then we have no need to care about it.
   If a driver doesn't work, we should not include it.

If a driver doesn't work, then it should be fixed.


It is appalling that you should so conveniently trim my words for me.
What I added to the above is:

"The only exceptions are where there is a concrete plan to make a
non-working driver into a working one."

So, if you are volunteering to fix the driver, great.  But there is no
need to keep it around on the random chance that someone may someday
fix it.

Thomas



Instead of arguing over a mailing list how about both of you go about fixing 
drivers?


*hides*

Barry (aka bddebian) 




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

aegis FTBFS (really aegis this time)

[Barry deFreese]

OK, in looking at the aegis FTBFS from the buildd it appears that we do not 
define RLIMIT_AS (Address Space Limit).


I am cross-posting this bug-hurd in case this is a missing implementation. 
On my Ubuntu GNU/Linux box, RLIMIT_AS is defined as 9.


However, even after the usual #ifndef "magic" the package fails on several 
of the tests and therefore still does not build.


Thanks,

Barry deFreese (aka bddebian) 




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

Re: Separating legacy drivers from device server.

[Barry deFreese]

- Original Message - 
From: "Gianluca Guida" <[EMAIL PROTECTED]>

To: 
Sent: Friday, March 03, 2006 7:22 AM
Subject: Separating legacy drivers from device server.


Hello,

I've recently been working on cleaning the drivers-related code.


Thanks,
Gianluca



Thanks a million to you and Thomas for working on this stuff!  What are the 
chances of getting the glue code updated (or better yet some type of more 
generic layer for device driver integration?).  I tried to use 2.6 stuff but 
am running into some strange issues.


Anything my dumb-ass can do to help?

Thanks again!

Barry (aka bddebian) 




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

Re: HurdExtras gaining momentum again

[Barry deFreese]

- Original Message - 
From: "Thomas Schwinge" <[EMAIL PROTECTED]>
To: ; ; "James A. Morrison" 
<[EMAIL PROTECTED]>; "Alfred M. Szmidt" <[EMAIL PROTECTED]>; "Manuel 
Menal" <[EMAIL PROTECTED]>

Sent: Thursday, April 13, 2006 11:55 AM
Subject: HurdExtras gaining momentum again



Hi!

Some of you might already have noticed--be it by participating in the
#hurd IRC channel or by following HurdExtras's mailing lists--that
HurdExtras is gaining momentum again.

This is due to Manuel Menal, who took the challenge of contacting the
authors (it's been years...) whose translators and tools he finally
committed to the repository.

 jfs -- a JFS translator
 mboxfs --  a mailbox file system translator
 memfs -- a memory based file system translator
 notice -- request file change notification messages
 pith -- the Perl interface to the Hurd
 run -- a simple run translator
 xmlfs -- a translator for accessing XML documents

Manuel also made sure that all those translators (and the others that are
already installed in the repository; apart from gopherfs and httpfs) are
basically functioning.


If _you_ want to contribute to this effort, feel free to contact the
hurdextras-hackers mailing list,
http://lists.nongnu.org/mailman/listinfo/hurdextras-hackers>.


One thing I noticed (as a participant of the hurdextras-hackers mailing
list) is that it seems that several messages didn't get through to the
list.

Does someone (Alfred, you're listed to be the list administrator for the
HurdExtras lists) still do moderation and other maintenance work for
these lists?  If nobody does and there are no objections from the other
participants of HurdExtras's mailing lists, I'd offer to take that over;
as the audience knows, I'm also doing moderation and maintenance work for
all of the other Hurd mailing lists--to the complete satisfaction of
everybody, afaIct.


Regards,
Thomas



Your forgot procfs :-)  So is this momentum the same momentum that 
gnumachrevival got?  Apologies for the negativity but we tend to be a lot of 
talk :-)


Thanks,

Barry deFreese (aka bddebian) 




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

Re: Google's Summer of Code 2006

[Barry deFreese]

- Original Message - 
From: "Giuseppe Scrivano" <[EMAIL PROTECTED]>

To: "Pierre THIERRY" <[EMAIL PROTECTED]>
Cc: 
Sent: Thursday, April 20, 2006 5:56 PM
Subject: Re: Google's Summer of Code 2006



Pierre THIERRY <[EMAIL PROTECTED]> writes:

Translators

- CIFS/SMB
Actually a samba translator is present in the hurd-extras project. 
Probably

it is a bit broken at the moment as I haven't used/tested it from about 2
years.

Thanks,
Giuseppe


Yes it's broken.  It depends on Samba and Samba won't build for us at the 
moment.  Full of PATH_MAX stuff IIRC.


Thanks,

Barry deFreese (aka bddebian) 




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

Re: Google's Summer of Code 2006

[Barry deFreese]

- Original Message - 
From: Matheus Morais

To: bug-hurd@gnu.org
Sent: Monday, April 24, 2006 10:49 AM
Subject: Re: Google's Summer of Code 2006


I had read Thomas last task about sound support on gnumach and I'm very 
interested in put that job done. Unfortunately, I have no enough skills for 
that and sounds interesting to me use SoC and one >mentor to get this task.


I already tryed find some mentor in project about port debian-installer to 
GNU/Debian Hurd but I've no success in this search. I think all @debian are 
very busy for this kind of project. ;P


If anyone could mentoring me in the gnumach sound task, I could be able to 
write that sound support.



Thanks

Matheus Morais



Matheus,

If I recall correctly, Colin Watson had gotten pretty far on porting D-I to 
Hurd but was still having an issue with booting I think.


Barry deFreese (aka bddebian) 




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

Re: I'd like to port Mach to x86_64, what should I do?

[Barry deFreese]

- Original Message - 
From: "stuarthu" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, April 26, 2006 9:10 AM
Subject: I'd like to port Mach to x86_64, what should I do?


   Hi every one, I'm a newbie on Mach and lack the experience. But I am 
going to take some effort on it. I have a x86_64 pc in my home, so I am 
going to port Mach to it. What should I do?




Pray a lot and buy lots of Aspirin ;-)

You may want to check out the hurdppc project on Savannah as I believe it 
had more of other arch support at least in the tree, though not implemented. 
I think all other archs have been ripped out of the gnumach-1-branch. 
Though I could certainly be wrong, it happens often :-)


Good luck!

Barry deFreese (aka bddebian) 




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

Re: _POSIX_THREADS in

[Barry deFreese]

- Original Message - 
From: "Roland McGrath" <[EMAIL PROTECTED]>

To: "Michael Banck" <[EMAIL PROTECTED]>
Cc: 
Sent: Thursday, April 27, 2006 3:13 PM
Subject: Re: _POSIX_THREADS in 



While reading the patch I noticed that you #defined _POSIX_THREADS to -1
in it.  I thought we have a posix thread implementation provided by
libpthread, so I am a bit confused.  Is this about something else?


I won't define it until we have a real libpthread implementation that
interacts correctly with libc and has all the right hairy semantics.
An extra libpthread that is not integrated with libc will never be a true
POSIX implementation.



This is going to be a dumb question, but what would that take?

Thanks,

Barry deFreese (aka bddebian)


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

Re: _POSIX_THREADS in

[Barry deFreese]

- Original Message - 
From: "Roland McGrath" <[EMAIL PROTECTED]>

To: "Barry deFreese" <[EMAIL PROTECTED]>
Cc: 
Sent: Friday, April 28, 2006 8:34 PM
Subject: Re: _POSIX_THREADS in 



> I won't define it until we have a real libpthread implementation that
> interacts correctly with libc and has all the right hairy semantics.
> An extra libpthread that is not integrated with libc will never be a 
> true

> POSIX implementation.

This is going to be a dumb question, but what would that take?


When I've referred before to a "total revamp of hurd libc", that's pretty
much it.  I'd like to more or less start over on signals, the hurd 
critical

section stuff, and probably revisit all the locking schemes from scratch.
This is necessary to do POSIX semantics for signals, cancellation, and
their pthreads interactions, correctly and robustly.


So get to work. ;-)  j/k.  I'd love to take this on but probably way over my 
head?


Thanks,

Barry deFreese (aka bddebian) 




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

Re: GNU Mach: enabling all (working) device drivers by default?

[Barry deFreese]

How about we move all the drive into userspace? ;-)

Barry


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

[bug #17808] NULL timeval does not return current date/time in futimes.c

[Barry deFreese]

URL:
  <http://savannah.gnu.org/bugs/?17808>

 Summary: NULL timeval does not return current date/time in
futimes.c
 Project: The GNU Hurd
Submitted by: bddebian
Submitted on: Tuesday 09/19/2006 at 18:07
Category: glibc
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Barry deFreese
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open
 Reproducibility: Every Time
  Size (loc): None
 Planned Release: None
  Effort: 0.00

___

Details:

Hello,

In sysdeps/mach/hurd/futimes.c, when passed a NULL timeval struct, it is
supposed to return the current date/time and does not.

Attached is a patch that Alfred helped create that does work but may not be
the best solution.

I have sent an e-mail to the libc-alpha mailing list requesting a review.

Thanks.





___

File Attachments:


---
Date: Tuesday 09/19/2006 at 18:07  Name: futimes.diff  Size: 1.02KB   By:
bddebian
futimes.diff
<http://savannah.gnu.org/bugs/download.php?file_id=10804>

___

Reply to this item at:

  <http://savannah.gnu.org/bugs/?17808>

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[task #5878] Backport code from GNU Mach's trunk to gnumach-1-branch: i386_set_gdt, i386_get_gdt

[Barry deFreese]

Follow-up Comment #2, task #5878 (project hurd):

The kernel descriptors in seg.h are completely different and you think this
is really that trivial?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

Re: mach 4

[Barry deFreese]

- Original Message - 
From: "girish" <[EMAIL PROTECTED]>

To: 
Sent: Thursday, October 05, 2006 12:32 PM
Subject: mach 4




hello. i am newbie to mach kernels.

my plan is to port mach kernel to MIPS Malta evaluation board.  i  have 
done some experience on porting NetBSD & Linux kernels for MIPS  Malta 
board. idea is to experiment with mach threads vis-a-vis NPTL/ TLS of 
MIPS.


where should i start - with mach4?

any help is greatly appreciated!

thanks.
girish.



Are you talking specifically about gnumach or pure Mach 4?  I know that 
gnumach does not have NPTL and possibly an incomplete TLS implementation.


Barry deFreese (aka bddebian) 




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

Re: Recent TODO list

[Barry deFreese]

- Original Message - 
From: "Shakthi Kannan" <[EMAIL PROTECTED]>

To: 
Sent: Friday, October 27, 2006 8:40 AM
Subject: Recent TODO list



Hi,

Where can I find the latest TODO list for GNU Hurd?

Thanks,

SK

--
Shakthi Kannan
http://www.shakthimaan.com



Shakthi,

There are bug and task lists on http://savannah.gnu.org/projects/hurd/  that 
could certainly be worked on. :-)



Barry deFreese (aka bddebian) 




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

Gnumach warnings clean-up round 1

[Barry deFreese]

Hey folks,

I was looking at cleaning up many of the warnings when building 
gnumach-1-branch.  I have only gotten through the gnumach/ipc/ dir so far 
but before I went any further I wanted some opinions on whether I was way 
off base on what I have done so far??


Thanks,

Barry deFreese (aka bddebian)



gnumach_1_warnings_1.diff
Description: Binary data
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Gnumach warnings clean-up round 1

[Barry deFreese]

- Original Message - 
From: "Samuel Thibault" <[EMAIL PROTECTED]>

To: "Barry deFreese" <[EMAIL PROTECTED]>
Cc: 
Sent: Saturday, October 28, 2006 4:04 PM
Subject: Re: Gnumach warnings clean-up round 1



Hi,

Does GNU mach's printf support %p?

Samuel



According to printf.c it does and it seems to work!?

Barry


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

Re: Gnumach warnings clean-up round 1

[Barry deFreese]

- Original Message - 
From: "Thomas Schwinge" <[EMAIL PROTECTED]>

To: "Barry deFreese" <[EMAIL PROTECTED]>; 
Sent: Saturday, October 28, 2006 7:20 PM
Subject: Re: Gnumach warnings clean-up round 1

Thomas,

Thanks!  I don't think I should have "broken" anything, I was more worried 
about the way I handled some of them.  Such as adding string.h to 
/include/sys and adding some of the other header files.


The %p one is even a bit of a question.  I believe %p is correct but I also 
dropped the 0x and maybe I shouldn't have?


Thanks again!

Barry 




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

Savannah task 5878 - port user_gdt

[Barry deFreese]

Hey folks,

I finally think I have the i386_{get,set}_gdt stuff from oskit ported into 
the gnumach branch.  I haven't tested the gdt functionality but it does 
build and boot.


Let me know what you think.

Thanks,

Barry deFreese (aka bddebian)



gnumach_user_gdt.diff
Description: Binary data
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Savannah task 5878 - port user_gdt

[Barry deFreese]

- Original Message - 
From: "Samuel Thibault" <[EMAIL PROTECTED]>

To: "Barry deFreese" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, October 30, 2006 3:54 AM
Subject: Re: Savannah task 5878 - port user_gdt



Hi,

Barry deFreese, le Sun 29 Oct 2006 22:30:12 -0500, a écrit :
I finally think I have the i386_{get,set}_gdt stuff from oskit ported 
into

the gnumach branch.  I haven't tested the gdt functionality but it does
build and boot.


Great!
See my comments below.

diff -Nurp gnumach-1-10292006.org/i386/i386/gdt.h 
gnumach-1-10292006/gnumach/i386/i386/gdt.h
--- gnumach-1-10292006.org/i386/i386/gdt.h 2006-10-29 18:26:18.0 
+
+++ gnumach-1-10292006/gnumach/i386/i386/gdt.h 2006-10-29 
19:49:34.0 +

@@ -59,7 +59,9 @@
to allocate */
#define GDTSZ   0x300   /* size of gdt table */
#else   /* PS2 */
-#define GDTSZ 11
+#define USER_GDT 0x48
+#define GDTSZ (0x80/8)
+#define USER_GDT_SLOTS 2
#endif  /* PS2 */


As I told you on irc, GDTS should be increased to 13, (because it was 11
and we're adding 2 slots), not 0x80/8 (which makes 16).

Else it looks fine.  This of course needs a few tests before committing.

Samuel



OK, I'm trying to do some testing and not having much luck.  However, I also 
noticed that i386_{get,set}_gdt is not getting in mach_i386.h.  What am I 
missing there?  Do I need to do some MiG magic to get it from mach_i386.defs 
to mach_i386.h?


Thanks!

Barry deFreese (aka bddebian)



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

Re: Drop i860 and PS2 support ?

[Barry deFreese]

- Original Message - 
From: "Constantine Kousoulos" <[EMAIL PROTECTED]>

Cc: 
Sent: Thursday, November 02, 2006 8:05 AM
Subject: Re: Drop i860 and PS2 support ?


From my very brief experience with GNU Mach, i came to realise that it is 
filled with oldies that are not needed anymore. So, whoever vollunteers to 
clean up some of them, is more than welcome.


Constantine



I'd happily work on removing some of this cruft as part of my warnings 
clean-up, if I could just get some response. ;-)


Thanks,

Barry deFreese (aka bddebian) 




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

Re: Drop i860 and PS2 support ?

[Barry deFreese]

- Original Message - 
From: "Samuel Thibault" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, November 01, 2006 6:36 PM
Subject: Re: Drop i860 and PS2 support ?



Samuel Thibault, le Thu 02 Nov 2006 00:17:57 +0100, a écrit :

The memory mapping code is a bit cluttered with i860-specific hacks, and
the pic/pit/gdt/clock code is clutter with PS2-specific hacks.

Maybe we should drop the support for these oldies?


Put another way for more probability of success:

Will anyone complain if I drop the support?

Samuel




Not I. :)

Barry 




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

More gnumach cleanup

[Barry deFreese]

Heya folks,

I'm still hoping to hear from Guillem and Thomas to see if adding string.h 
makes sense for memset and memcpy, but be that as it may, does anyone see an 
issue with replacing all instances of bzero/bcopy with memset/memcpy ?


Thanks,

Barry deFreese (aka bddebian) 




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

Re: Savannah task 5878 - port user_gdt

[Barry deFreese]

- Original Message - 
From: "Barry deFreese" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, October 31, 2006 10:55 PM
Subject: Re: Savannah task 5878 - port user_gdt




- Original Message - 
From: "Samuel Thibault" <[EMAIL PROTECTED]>

To: "Barry deFreese" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, October 30, 2006 3:54 AM
Subject: Re: Savannah task 5878 - port user_gdt



Hi,

Barry deFreese, le Sun 29 Oct 2006 22:30:12 -0500, a écrit :
I finally think I have the i386_{get,set}_gdt stuff from oskit ported 
into

the gnumach branch.  I haven't tested the gdt functionality but it does
build and boot.


Great!
See my comments below.

diff -Nurp gnumach-1-10292006.org/i386/i386/gdt.h 
gnumach-1-10292006/gnumach/i386/i386/gdt.h
--- gnumach-1-10292006.org/i386/i386/gdt.h 2006-10-29 18:26:18.0 
+
+++ gnumach-1-10292006/gnumach/i386/i386/gdt.h 2006-10-29 
19:49:34.0 +

@@ -59,7 +59,9 @@
to allocate */
#define GDTSZ   0x300   /* size of gdt table */
#else   /* PS2 */
-#define GDTSZ 11
+#define USER_GDT 0x48
+#define GDTSZ (0x80/8)
+#define USER_GDT_SLOTS 2
#endif  /* PS2 */


As I told you on irc, GDTS should be increased to 13, (because it was 11
and we're adding 2 slots), not 0x80/8 (which makes 16).

Else it looks fine.  This of course needs a few tests before committing.

Samuel



OK, I'm trying to do some testing and not having much luck.  However, I 
also noticed that i386_{get,set}_gdt is not getting in mach_i386.h.  What 
am I missing there?  Do I need to do some MiG magic to get it from 
mach_i386.defs to mach_i386.h?


Thanks!

Barry deFreese (aka bddebian)



OK thanks to Samuels patience and help, I have an improved patch that does 
work and has been moderately tested.


Thanks!

Barry deFreese (aka bddebian)



gnumach_i386_gdt.diff
Description: Binary data
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Savannah task 5878 - port user_gdt

[Barry deFreese]

- Original Message - 
From: "Samuel Thibault" <[EMAIL PROTECTED]>

To: "Barry deFreese" <[EMAIL PROTECTED]>
Cc: 
Sent: Saturday, November 04, 2006 8:40 PM
Subject: Re: Savannah task 5878 - port user_gdt



Hi,

Barry deFreese, le Sat 04 Nov 2006 20:14:08 -0500, a écrit :

I have an improved patch that does work and has been moderately
tested.


--- ChangeLog 4 Nov 2006 23:32:21 - 1.128.2.159
+++ ChangeLog 5 Nov 2006 01:04:41 -
@@ -1,3 +1,15 @@
+* i386/i386/gdt.h (USER_GDT, USER_GDT_SLOTS): New macros.

You should also note that GDTSZ got modified too.

+* i386/i386/thread.h (struct i386_machine_state): New member 
user_gdt.


And that gdt.h is included.

+* Thanks to Samuel Thibault for fix ups and testing!

Not needed :)

--- i386/i386/gdt.h 4 Nov 2006 23:32:21 - 1.2.2.1
+++ i386/i386/gdt.h 5 Nov 2006 01:05:01 -
@@ -49,8 +49,9 @@
#define USER_FPREGS 0x40 /* user-mode access to saved
floating-point registers */

-#define GDTSZ 11
-
+#define GDTSZ 13
+#define USER_GDT 0x48
+#define USER_GDT_SLOTS 2

You should define GDTSZ after USER_GDT and USER_GDT_SLOTS, and GDTSZ
should then rather be (USER_GDT/8 + USER_GDT_SLOTS)

Index: linux/src/include/linux/head.h
===
RCS file: /cvsroot/hurd/gnumach/linux/src/include/linux/Attic/head.h,v
retrieving revision 1.1
diff -u -r1.1 head.h
--- linux/src/include/linux/head.h 26 Apr 1999 05:56:28 - 1.1
+++ linux/src/include/linux/head.h 5 Nov 2006 01:05:03 -
@@ -5,7 +5,10 @@
 unsigned long a,b;
} desc_table[256];

-extern desc_table idt,gdt;
+/* XXX Linux code doesn't use idt/gdt? */
+/*
+ * extern desc_table idt,gdt;
+ */

They shouldn't ever use idt/gdt directly.

Samuel



Samuel,

Thanks for the feedback.  How's this one?

Barry



gnumach_i386_gdt_2.diff
Description: Binary data
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Gnumach clean part 1 redo

[Barry deFreese]

OK, I limited my clean up patch to just the implicit declaration warnings 
for memset/memcpy and replaced all bzero/bcopy calls with memset/memcpy.


 * include/string.h New file
 * ipc/ipc_entry.c Include string.h for memset
 * ipc/ipc_space.c Likewise
 * device/kmsg.c Likewise
 * kern/boot_script.c Likewise
 * kern/bootstrap.c Likewise
 * device/cons.c Include string.h. Replace bzero() with memset()
 * ipc/ipc_object.c Likewise
 * ipc/mach_debug.c Likewise
 * kern/act.c Likewise
 * kern/eventcount.c Likewise
 * kern/lock.c Likewise
 * kern/lock_mon.c Likewise
 * kern/mach_clock.c Likewise
 * kern/xpr.c Likewise
 * kern/zalloc.c Likewise
 * vm/vm_debug.c Likewise
 * vm/vm_object.c Likewise
 * vm/vm_resident.c Likewise
 * device/cirbuf.c Include string.h. Replace bcopy() with memcpy()
 * i386/i386/trap.c Likewise
 * i386/i386at/kd_event.c Likewise
 * ipc/ipc_kmsg.c Likewise
 * ipc/ipc_port.c Likewise
 * kern/host.c Likewise
 * kern/pc_sample.c Likewise
 * kern/processor.c Likewise
 * kern/task.c Likewise
 * device/dev_pager.c Include string.h. Replace bzero() with memset() and 
bcopy() with memcpy()

 * device/net_io.c Likewise
 * i386/i386/fpu.c Likewise
 * i386/i386/iopb.c Likewise
 * i386/i386/mp_desc.c Likewise
 * i386/i386/pcb.c Likewise
 * i386/i386/phys.c Likewise
 * i386/i386/user_ldt.c Likewise
 * i386/i386at/immc.c Likewise
 * i386/intel/pmap.c Likewise
 * kern/syscall_emulation.c Likewise
 * vm/vm_kern.c Likewise
 * include/mach/mig_support.h  Remove define for memcpy to bcopy


Please commit if everything looks OK.

Thanks!

Barry deFreese (aka bddebian)



gnumach_string_clean.diff
Description: Binary data
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: gnumach device/cirbuf.c device/cons.c device/de... [gnumach-1-branch]

[Barry deFreese]

- Original Message - 
From: "Thomas Schwinge" <[EMAIL PROTECTED]>
To: ; "Samuel Thibault" <[EMAIL PROTECTED]>; 
"Barry deFreese" <[EMAIL PROTECTED]>

Sent: Sunday, November 05, 2006 3:31 PM
Subject: Re: gnumach device/cirbuf.c device/cons.c device/de... 
[gnumach-1-branch]



Hello!


Heya


CVSROOT: /cvsroot/hurd
Module name: gnumach
Branch:  gnumach-1-branch
Changes by: Samuel Thibault  06/11/05 18:54:52

[...]
  * include/string.h: New file.


This file is ``Copyright (C) 2006 Barry deFreese.''.  Wouldn't we rather
want that to be ``Copyright FSF''?


Probably.



  * i386/i386/fpu.c (fpu_set_state, fpu_get_state) fp_load)


One `)' should be a `,', I guess.


Samuel has already fixed I think he said.


As for the other `string.h' / `memcpy()' / `memset()' changes, I'm not
going to verify them one-by-one as I expect that Samuel has already done
that before checking it in.


So, then to both of you: thanks for doing that!  :-)


No problem.


Did someone already check if mig itself (i.e. migcom) puts `bcopy()' and
`bzero()' invocations in its generated files?


Yes, it does not afaik


Regards,
Thomas


Barry deFreese (aka bddebian) 




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

Re: [task #5726] GCC built-in functions

[Barry deFreese]

- Original Message - 
From: "Thomas Schwinge" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Thomas Schwinge" <[EMAIL PROTECTED]>; "Samuel 
Thibault" <[EMAIL PROTECTED]>; 

Sent: Sunday, November 05, 2006 4:47 PM
Subject: [task #5726] GCC built-in functions




Update of task #5726 (project hurd):

 Status:None => In Progress
Assigned to:None => sthibaul
  To be done before: => Samuel, Barry, this 
can

be closed now, I guess?  Or is anything left to be done w.r.t. this task?




Thomas,

I intend on doing some more but this particular task can be closed I 
supposed.  Samuel?


Thanks,

Barry 




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

Re: gnumach ChangeLog i386/i386/gdt.h i386/i386/pcb... [gnumach-1-branch]

[Barry deFreese]

- Original Message - 
From: "Samuel Thibault" <[EMAIL PROTECTED]>

To: "Roland McGrath" <[EMAIL PROTECTED]>
Cc: "Thomas Schwinge" <[EMAIL PROTECTED]>; ; "Barry 
deFreese" <[EMAIL PROTECTED]>; 

Sent: Sunday, November 05, 2006 4:49 PM
Subject: Re: gnumach ChangeLog i386/i386/gdt.h i386/i386/pcb... 
[gnumach-1-branch]




Roland McGrath, le Sun 05 Nov 2006 13:41:43 -0800, a écrit :

> -   else if (thread == current_thread()) {
> -   struct x86_desc template = {0, 0, 0, ACC_P, 0, 0 ,0};
> +   else {
> +   struct real_descriptor template = {0, 0, 0, ACC_P, 0, 0 
> ,0};


This can't be right (changing the if).


Uh, didn't notice that.  Barry, do you remember why you dropped the if?

Samuel



The only thing I intended to change there was x_86_desc -> real_descriptor 
so I don't know what happened to the if.  Very strange.


Barry 




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

Gnumach kern/strings.h

[Barry deFreese]

OK, trying to do more clean-up, I ran across kern/strings.h which has 
declarations for many of the string handling functions which I had intended 
on adding to my include/string.h.


However, it only seems to be used in ddb/ and kern/ files.  So my dilemna is 
do I leave stings.h alone and let the files currently using them continue to 
do so or change everything to utilize include/string.h?


Thanks,

Barry deFreese (aka bddebian) 




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

Re: Gnumach kern/strings.h

[Barry deFreese]

- Original Message - 
From: "Claudio Fontana" <[EMAIL PROTECTED]>

To: "Barry deFreese" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, November 06, 2006 10:14 PM
Subject: Re: Gnumach kern/strings.h



Hello,

--- Barry deFreese <[EMAIL PROTECTED]> wrote:


OK, trying to do more clean-up, I ran across
kern/strings.h which has
declarations for many of the string handling
functions which I had intended
on adding to my include/string.h.

However, it only seems to be used in ddb/ and kern/
files.  So my dilemna is
do I leave stings.h alone and let the files
currently using them continue to
do so or change everything to utilize
include/string.h?

Thanks,

Barry deFreese (aka bddebian)


I am out of lurking mode to ask, is this to be the
regular header that application developers include
under your system to see all standard string functions
declared?
In this case we'd expect them to be available from
string.h

strings.h was the header used to declare old stuff
like
bzero, bcopy, bcmp, etc.

Sorry if I'm OT, I live in userland.

Bye,

Claudio



Claudio,

That was my intent yes.  BTW, bzero, bcopy, bcmp, etc aren't currently 
declared in kern/strings.h ;-)


Thanks,

Barry deFreese (aka bddebian) 




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

Re: [task #5487] cthreads -> pthreads

[Barry deFreese]

- Original Message - 
From: "Constantine Kousoulos" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, November 07, 2006 8:21 AM
Subject: Re: [task #5487] cthreads -> pthreads



Thomas Schwinge wrote:

Follow-up Comment #1, task #5487 (project hurd):

Attached is the work that Vicente Hernando Ara has been doing years ago, 
see

<http://web.archive.org/web/20040213013636/es.gnu.org/~zenton/Pthread/>.


This link is obsolete.


From Savannah (http://savannah.gnu.org/task/?5487):
"... To gain greater portability, the libraries and servers should be 
ported to pthreads (which we also have a mostly functional implementation 
for in the Hurd)."


What exactly does the term "mostly functional implementation" mean?

Has anyone considered using GNU Portable Threads 
(http://www.gnu.org/software/pth/) with the Hurd? Maybe they are easier to 
become "fully functional" since they are "portable".


Sorry for the overdose of questions.

Thanks,
Constantine


Constantine,

Does this mean you are done with the 2.6 driver code? ;-)

Barry deFreese (aka bddebian) 




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

Gnumach clean-up Round 2

[Barry deFreese]

Here is a patch for another round of cleanup.  This gets rid of warnings for 
strcmp, strlen, and printf.


 * include/stdio.h  New file
 * include/string.h New declarations:
   *  strcmp, strlen, strncmp, strcpy, strncopy, strsep, strchr, strrchar
 * chips/busses.c  Include string.h and stdio.h
 * ipc/ipc_entry.c Include stdio.h
 * ipc/ipc_hash.c  Likewise
 * ipc/ipc_kmsg.c Likewise
 * ipc/ipc_notify.c Likewise
 * ipc/ipc_object.c Likewise
 * ipc/ipc_port.c Likewise
 * ipc/ipc_pset.c Likewise
 * ipc/mach_msg.c Likewise
 * ipc/mach_port.c Likewise
 * ipc/mach_rpc.c Likewise
 * kern/debug.c Likewise
 * kern/eventcount.c Likewise
 * kern/ipc_kobject.c Likewise
 * kern/pc_sample.c Likewise
 * kern/sched_prim.c Likewise
 * kern/thread.c Likewise
 * kern/zalloc.c Likewise
 * vm/vm_fault.c Likewise
 * vm/vm_map.c Likewise
 * vm/vm_object.c Likewise
 * vm/vm_resident.c Likewise
 * kern/bootstrap.c Include stdio.h, remove include for kern/strings.h
 * kern/printf.c Likewise
 * kern/strings.c Include sys/types.h, string.h, remove include for 
kern/strings.h


If it looks OK, please commit.

Thank you,

Barry deFreese (aka bddebian)




gnumach_clean_2.diff
Description: Binary data
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Gnumach clean-up Round 2

[Barry deFreese]

- Original Message - 
From: "Thomas Bushnell BSG" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, November 07, 2006 12:42 PM
Subject: Re: Gnumach clean-up Round 2



On Tue, 2006-11-07 at 12:18 -0500, Barry deFreese wrote:
Here is a patch for another round of cleanup.  This gets rid of warnings 
for

strcmp, strlen, and printf.


I don't think we should have a file called  unless it's going
to support all of stdio.   is a much better name for a header
that includes only that.

I don't see mention of deleting the superfluous files in ; why
not?

Thomas


Thomas,

Thanks for the reply.  My intent would be to have a full stdio at some 
point.  Is that the wrong approach?


I didn't delete any files, what would I have deleted?  Strings.h?

Thanks again,

Barry 




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

Re: Gnumach clean-up Round 2

[Barry deFreese]

Here is a patch for another round of cleanup.  This gets rid of warnings 
for

strcmp, strlen, and printf.

 * include/printf.h  New file
 * include/string.h New declarations:
   *  strcmp, strlen, strncmp, strcpy, strncopy, strsep, strchr, strrchar
 * chips/busses.c  Include string.h and printf.h
 * ipc/ipc_entry.c Include printf.h
 * ipc/ipc_hash.c  Likewise
 * ipc/ipc_kmsg.c Likewise
 * ipc/ipc_notify.c Likewise
 * ipc/ipc_object.c Likewise
 * ipc/ipc_port.c Likewise
 * ipc/ipc_pset.c Likewise
 * ipc/mach_msg.c Likewise
 * ipc/mach_port.c Likewise
 * ipc/mach_rpc.c Likewise
 * kern/debug.c Likewise
 * kern/eventcount.c Likewise
 * kern/ipc_kobject.c Likewise
 * kern/pc_sample.c Likewise
 * kern/sched_prim.c Likewise
 * kern/thread.c Likewise
 * kern/zalloc.c Likewise
 * vm/vm_fault.c Likewise
 * vm/vm_map.c Likewise
 * vm/vm_object.c Likewise
 * vm/vm_resident.c Likewise
 * kern/bootstrap.c Include printf.h, remove include for kern/strings.h
 * kern/printf.c Likewise
 * kern/strings.c Include sys/types.h, string.h, remove include for
kern/strings.h

If it looks OK, please commit.

Thank you,

Barry deFreese (aka bddebian)



OK, I updated this to use include/printf.h instead of include/stdio.h.


Thanks,

Barry 


gnumach_clean_2.1.diff
Description: Binary data
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Gnumach clean-up Round 2

[Barry deFreese]

Third time is a charm?

 * kern/debug.c  New function do_cnputc().
 * kern/strings.h  Remove file
 * ddb/db_output.c Include printf.h and remove forward declaration for 
_doprnt()

 * include/stdio.h  New file
 * include/string.h New declarations:
   *  strcmp, strlen, strncmp, strcpy, strncopy, strsep, strchr, strrchar
 * chips/busses.c  Include string.h and stdio.h
 * ipc/ipc_entry.c Include stdio.h
 * ipc/ipc_hash.c  Likewise
 * ipc/ipc_kmsg.c Likewise
 * ipc/ipc_notify.c Likewise
 * ipc/ipc_object.c Likewise
 * ipc/ipc_port.c Likewise
 * ipc/ipc_pset.c Likewise
 * ipc/mach_msg.c Likewise
 * ipc/mach_port.c Likewise
 * ipc/mach_rpc.c Likewise
 * kern/debug.c Likewise
 * kern/eventcount.c Likewise
 * kern/ipc_kobject.c Likewise
 * kern/pc_sample.c Likewise
 * kern/sched_prim.c Likewise
 * kern/thread.c Likewise
 * kern/zalloc.c Likewise
 * vm/vm_fault.c Likewise
 * vm/vm_map.c Likewise
 * vm/vm_object.c Likewise
 * vm/vm_resident.c Likewise
 * kern/bootstrap.c Include stdio.h, remove include for kern/strings.h
 * kern/printf.c Likewise
 * kern/strings.c Include sys/types.h, string.h, remove include for
kern/strings.h


Thanks,

Barry deFreese (aka bddebian) 


gnumach_clean_2.2.diff
Description: Binary data
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Gnumach clean: Need advice, re Header files

[Barry deFreese]

Hi again,

Looking at more of the implicit declarations of functions (and there are a 
ton).  The question now is, where to declare them and/or put the header 
files.  printf.h was a little bit of a special case because it didn't exist. 
But, take, for example, panic().  It is instantiated in debug.c but used in 
a ton of .c files.  There is a kern/debug.h but it's not even included in 
many of the files utilizing panic().  Same goes for copyin, copyout, splx, 
and many, many more.


Samuel, Thomas, and I were discussing it breifly on IRC and thought maybe 
moving the header files to include/ and changing the source files might make 
sense.  In this case, I would move kern/debug.h, add a declaration for 
panic(), and move the file to include/debug.h and change all the #includes?


Anyone else have any thoughts on this?

Thanks,

Barry deFreese (aka bddebian) 




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

Re: Gnumach clean: Need advice, re Header files

[Barry deFreese]

- Original Message - 
From: "Roland McGrath" <[EMAIL PROTECTED]>

To: "Barry deFreese" <[EMAIL PROTECTED]>
Cc: 
Sent: Wednesday, November 08, 2006 11:07 PM
Subject: Re: Gnumach clean: Need advice, re Header files



include/ is for installed headers.  None of those should be added.



Roland,

OK, thanks for the reply.  Then should my printf.h move under kern/ where 
printf.c is?  Also, is it proper to add a declaration of panic() to 
kern/debug.h and then include debug.h in the appropriate files?


Thanks again,

Barry 




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

Re: Working on stuff / statement from tschwinge (was: Gnumach clean:Need advice, re Header files)

[Barry deFreese]

- Original Message - 
From: "Thomas Schwinge" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; 
Sent: Thursday, November 09, 2006 7:50 AM
Subject: Working on stuff / statement from tschwinge (was: Gnumach 
clean:Need advice, re Header files)



Thomas,

Thanks for writing this.  I have to admit, I was a little offended last 
night myself.  I realize that the work I have been doing is minimal and not 
exactly "important" or beneficial for the project.  I also realize that I am 
clueless and probably ask a lot of dumb questions.  But these types of tasks 
do get me an entry into the code without doing any real damage and I am DAMN 
tired of talking, talking, talking on IRC and mailing lists with very few 
actually DOING anything to progress the project.


I, for one, very much appreciate the help that you and Samuel (and others of 
course) have given me and I hope that me getting in and doing "stupid" work 
can motivate more smart people to start digging into the code more.


Thanks again!

Barry deFreese (aka bddebian) 




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

Re: Working on stuff / statement from tschwinge (was: Gnumachclean: Need advice, re Header files)

[Barry deFreese]

- Original Message - 
From: "Thomas Bushnell BSG" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; 
Sent: Thursday, November 09, 2006 1:50 PM
Subject: Re: Working on stuff / statement from tschwinge (was: 
Gnumachclean: Need advice, re Header files)





I think Roland's email was a little over-hasty, to be sure.  Let's just
not fret about one message that was over-hasty and import too much to
it, ok?

As for the technical issue, Roland is mostly but not entirely right
about what gnumach/include is for.

It has both the interface files, and pseudo-clones of C library headers,
which don't get installed because the C library has better versions.  In
that category are , , ,
, , ,
, and , by my count.

By putting such headers in gnumach/include, the relevant kernel code is
easier to understand, because the user will expect that the file named
 or  does more or less what the normal C library
file does, and calling those  or  would
make the reader have to wonder or remember what they are.

It would not be inappropriate to put  there too, since it
serves the same sort of function.  However,  does not belong
there, and belongs in whichever directory holds the relevant functions.

Thomas


Thomas,

Thanks.  Though apparently some consider my "work" useless, I am in the 
middle of writing a patch putting printf.h back into kern/ as well as adding 
declarations for panic() to debug..h and including accordingly.


Thanks!

Barry deFreese (aka bddebian)



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

Re: Gnumach Cleanup Round 3 - Move printf.h and add panicdeclaration

[Barry deFreese]

- Original Message - 
From: "Thomas Bushnell BSG" <[EMAIL PROTECTED]>

To: "Barry deFreese" <[EMAIL PROTECTED]>
Cc: 
Sent: Thursday, November 09, 2006 8:05 PM
Subject: Re: Gnumach Cleanup Round 3 - Move printf.h and add 
panicdeclaration


Why the change to add parentheses to printf.c:_doprnt?  (If this is to
shut up a gcc warning, then it seems ok, I guess.)

We do not normally put comments on #include's saying why the file was
included for a couple reasons: it very quickly gets out of date, and it
doesn't really communicate anything very important.  Such comments
belong in the ChangeLog entry, something like this:

* ddb/db_command.c: Include  for panic.

Thomas


Thomas,

Yes it was to shut up a warning but apparently Samuel dropped it from the 
patch anyway, so I'll re-add later.  As for the comments they are all over 
the source, so I did that.  I will drop them on a subsequent patch.


Thanks,

Barry



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

Gnumach: locore.S copyin vs. copyinmsg

[Barry deFreese]

Hello again folks,

Looking at more cleanup stuff I run across implicit declarations for copyin, 
copyinmsg, copyout, and copyoutmsg.  From my extremely limited knowledge of 
assembler, copyin and copyinmsg look to be exactly the same.  Is there any 
reason not to drop all instances of copyinmsg in favor of copyin, since 
copyin seems to be a "standard"?


Here are parts of the code:

from locore.S:

ENTRY(copyin)
Entry(copyinmsg)
pushl   %esi
pushl   %edi/* save registers */



from asm.h:

#define ENTRY(x).globl EXT(x); .p2align TEXT_ALIGN; LEXT(x)
#define Entry(x).globl EXT(x); .p2align TEXT_ALIGN; LEXT(x)

Thanks!!

Barry deFreese (aka bddebian) 




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

Re: Gnumach: locore.S copyin vs. copyinmsg

[Barry deFreese]

- Original Message - 
From: "Thomas Bushnell BSG" <[EMAIL PROTECTED]>

To: "Samuel Thibault" <[EMAIL PROTECTED]>
Cc: "Barry deFreese" <[EMAIL PROTECTED]>; 
Sent: Friday, November 10, 2006 1:04 PM
Subject: Re: Gnumach: locore.S copyin vs. copyinmsg

Yeah, I already added declarations for copyinmsg and copyoutmsg in locore.h.

Thanks for the replies!

Barry 




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

Gnumach: spl.h vs machspl.h

[Barry deFreese]

Hi again folks,

OK, I am confused by something else. (I know big surprise :-) ).

i386/i386/spl.h
   #include ipl.h

i386/i386/ipl.h
   #ifdef __ASSEMBLER__
   #include 
...

i386/i386/machspl.h
   /* XXX replaced by... */
   #include 

First question is, is this an issue?  machspl.h doesn't seem to have any 
#ifdef _I386_MACHSPL_H_ wrapper around it.


Second question, is: Should machspl.h just be dropped and replace all 
instances with spl.h?


Thanks as always!

Barry deFreese (aka bddebian) 




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

Gnumach cleanup Round 4

[Barry deFreese]

Heya gang.

OK, I was working on a much bigger patch but got hung up on some of the
chario / tty stuff.  So I am sending what I have for now.

  * i386/i386/locore.h  New file
  * i386/i386/pcb.h  New file
  * i386/i386/spl.h  Add function declarations
  * i386/i386at/kd_event.h  New file
  * i386/i386at/kd_mouse.h  New file
  * i386/i386at/model_dep.h  New file
  * i386/i386at/kd.c  Include new kd_event.h and kd_mouse.h.
  * i386/i386at/kd.h  Remove prototypes for splx() and spltty().
  * i386/i386at/lpr.c  Remove prototypes for splx() and spltty().
  * ipc/mach_msg.c  Include new locore.h and pcb.h
  * kern/debug.c  Include new i386at/model_dep.h
  * kern/mach_clock.h  New file
  * kern/mach_clock.c  New includes:
* i386at/model_dep.h
* kern/mach_clock.h
* kern/queue.h
* kern/timer.h
  * kern/mach_factor.h  New file
  * kern/sched_prim.c  New includes:
* i386at/model_dep.h
* kern/mach_factor.h
  * kern/thread.c  Include new i386/pcb.h

Thanks!

Barry deFreese (aka bddebian)

Index: i386/i386/locore.h
===
RCS file: i386/i386/locore.h
diff -N i386/i386/locore.h
--- /dev/null	1 Jan 1970 00:00:00 -
+++ i386/i386/locore.h	12 Nov 2006 20:21:57 -
@@ -0,0 +1,39 @@
+/*
+ * Header file for printf type functions.
+ * Copyright (C) 2006 Free Software Foundation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef _MACHINE_LOCORE_H_
+#define _MACHINE_LOCORE_H_
+
+#include 
+#include 
+
+#include 
+
+extern int copyin (const void *userbuf, void *driverbuf, size_t cn);
+
+extern int copyinmsg (vm_offset_t userbuf, vm_offset_t driverbuf, size_t cn);
+
+extern int copyout (const void *userbuf, void *driverbuf, size_t cn);
+
+extern int copyoutmsg (vm_offset_t userbuf, vm_offset_t driverbuf, size_t cn);
+
+extern int call_continuation (continuation_t continuation);
+
+#endif /* _MACHINE__LOCORE_H_ */
+
Index: i386/i386/pcb.h
===
RCS file: i386/i386/pcb.h
diff -N i386/i386/pcb.h
--- /dev/null	1 Jan 1970 00:00:00 -
+++ i386/i386/pcb.h	12 Nov 2006 20:21:57 -
@@ -0,0 +1,61 @@
+/*
+ *
+ * Copyright (C) 2006 Free Software Foundation, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * Author: Barry deFreese.
+ */
+/*
+ *
+ *
+ */
+
+#ifndef _I386_PCB_H_
+#define _I386_PCB_H_
+
+#include 
+
+extern void pcb_init (thread_t thread);
+
+extern void pcb_terminate (thread_t thread);
+
+extern void pcb_collect (thread_t thread);
+
+extern kern_return_t thread_setstatus (
+   thread_tthread,
+   int flavor,
+   thread_state_t  tstate,
+   unsigned intcount);
+
+extern kern_return_t thread_getstatus (
+   thread_tthread,
+   int flavor,
+   thread_state_t  tstate,
+   unsigned int*count);
+
+extern void thread_set_syscall_return (
+   thread_tthread,
+   kern_return_t   retval);
+
+extern vm_offset_t user_stack_low (vm_size_t stack_size);
+
+extern vm_offset_t set_user_regs (
+   vm_offset_t stack_base,
+   vm_offset_t stack_size,
+   struct exec_info *exec_info,
+   vm_size_t   arg_size);
+
+#endif /* _I386_PCB_H_ */
Index: i386/i386/spl.h
===
RCS file: /cvsroot/hurd/gnumach/i386/i386/spl.h,v
retrieving revision 1.2
diff -u -p -r1.2 spl.h
--- i386/i386/spl.h	26 Apr 1999 05:26:12 -	1.2
+++ i386/i386/spl.h	12 Nov 2006 20:21:57 -
@@ -48,6 +48,28 @@ extern spl_t	(spldcm)(void);
 
 extern spl_t	(spl6)(void);
 
+extern int spl0 (void);
+
+extern int splsched (void);
+
+extern int splx (int n);
+
+extern int splsoftclock (void);
+
+extern void splon (int n

Re: Gnumach cleanup Round 4

[Barry deFreese]

- Original Message - 
From: "Samuel Thibault" <[EMAIL PROTECTED]>

To: "Barry deFreese" <[EMAIL PROTECTED]>
Cc: 
Sent: Sunday, November 12, 2006 6:47 PM
Subject: Re: Gnumach cleanup Round 4



Hi,

Barry deFreese, le Sun 12 Nov 2006 21:19:06 -0500, a écrit :

OK, I was working on a much bigger patch but got hung up on some of the
chario / tty stuff.  So I am sending what I have for now.


Ah, I misread it, so that patch was not so big, I commited most of it
(the obvious part).


  * i386/i386at/model_dep.h  New file



  * kern/debug.c  Include new i386at/model_dep.h
  * kern/mach_clock.c  New includes:
* i386at/model_dep.h


This poses problem.  We can't ask the kernel part to include some
i386-specific part.  For such things we have the machine/ symlink, but
it points to i386/i386/, not i386/i386at/ .  Any thoughts on this?

Samuel



Samuel,

Thanks, I thought about that too.  Unfortunately I'm not quite skilled 
enough yet to get the differences between what's in i386/ vs i386at/ .


Thanks,

Barry 




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

Re: Gnumach cleanup Round 4

[Barry deFreese]

- Original Message - 
From: "Roland McGrath" <[EMAIL PROTECTED]>

To: "Barry deFreese" <[EMAIL PROTECTED]>
Cc: 
Sent: Sunday, November 12, 2006 7:50 PM
Subject: Re: Gnumach cleanup Round 4



Decls for copyin et al do not belong in a machine header.



Roland,

I don't disagree.  Have a suggestion for a better place to declare it?

Thanks,

Barry


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

Gnumach cleanup - 'return type defaults to int'

[Barry deFreese]

As per Samuels request, here is a patch to clean up all warnings for
non-typed functions.

  * device/cons.c
* cninit()  Add void return type to function definition
* cngetc()  return type int
* cnmaygetc()  Likewise
* cnputc()  return type void
  * device/net_io.c
* net_del_q_info() return type void
* net_free_dead_infp() Likewise
* net_free_dead_entp() Likewise
  * device/chario.c
* tty_cts()  Likewise
  * i386/i386at/com.c
* comintr()  return type int
* comparm()  return type void
* comtimer()  Likewise
* fix_modem_state()  Likewise
* commodem_intr()  Likewise
* commctl()  return type int
* comstop()  return type int
  * i386/i386at/rtc.c
* rtcinit()  Likewise
* rtcput()  Likewise
* yeartoday()  return type int
* readtodc()  return type int
  * i386/i386at/iopl.c
* ioplopen()  return type int
* ioplclose()  return type int
  * i386/i386at/kd.c
* kd_io_map_open() return type void
* kd_io_map_close()  Likewise
* feep()  Likewise
* pause()  Likewise
* kd_debug_put()  Likewise
* cnpollc()  Likewise
* kdopen()  return type int
* kdclose()  return type void
* kdread()  return type int
* kdwrite()  Likewise
* kdportdeath()  Likewise
* kdsetbell()  Likewise
* kdgetkbent()  Likewise
* kdintr()  return type void
* kd_handle_ack()  return type void
* kd_resend()  Likewise
* do_modifier()  return type int
* kdstate2idx()  Likewise
* kdstart()  Likewise
* kdstop()  return type void
* kdinit()  Likewise
* kd_belloff()  Likewise
* kd_bellon()  Likewise
* kd_putc()  Likewise
* kd_setpos()  Likewise
* kd_scrollup()  Likewise
* kd_scrolldn()  Likewise
* kd_parseesc()  Likewise
* kd_parserest() Likewise
* kd_tab()  Likewise
* kd_cls()  Likewise
* kd_home()  Likewise
* kd_up()  Likewise
* kd_down()  Likewise
* kd_right()  Likewise
* kd_left()  Likewise
* kd_cr()  Likewise
* kd_cltobcur()  Likewise
* kd_cltopcur()  Likewise
* kd_cltoecur()  Likewise
* kd_clfrbcur()  Likewise
* kd_delln()  Likewise
* kd_insln()  Likewise
* kd_delch()  Likewise
* kd_erase()  Likewise
* kd_eraseln()  Likewise
* kd_insch()  Likewise
* kd_isupper() return type boolean_t
* kd_islower() Likewise
* kd_senddata()  return type void
* kd_sendcmd()  Likewise
* kd_cmdreg_read()  return type unsigned char
* kd_cmdreg_write()  return type void
* kd_mouse_drain()  Likewise
* set_kd_state()  Likewise
* kd_setleds1()  Likewise
* kd_setleds2()  Likewise
* cnsetleds()  Likewise
* kdreboot()  Likewise
* kd_kbd_magic()  return type int
  * i386/i386at/kd_event.c
* kbdinit()  return type void
* kbdopen()  return type int
* kbdclose()  return type void
* kbdioctl()  return type int
* kbdselect()  Likewise
* kbdread()  Likewise
* kdb_in_out()  return type void
* X_kdb_enter()  Likewise
* X_kdb_exit()  Likewise
* X_kdb_enter_init()  Likewise
* X_kdb_exit_init()  Likewise
  * i386/i386at/kd_mouse.c
* init_mouse_hw()  return type void
* mouseopen()  return type int
* serial_mouse_open()  return type void
* kd_mouse_open()  Likewise
* mouseclose()  Likewise
* serial_mouse_close()  Likewise
* kd_mouse_close()  Likewise
* mouseioctl()  return type int
* mouseselect()  Likewise
* mouseread()  Likewise
* mouseread()  return type void
* mouse_handle_byte()  Likewise
* mouse_packet_mouse_system_mouse()  Likewise
* mouse_packet_microsoft_mouse()  Likewise
* ibm_ps2_mouse_open()  Likewise
* ibm_ps2_mouse_close()  Likewise
* mouse_packet_ibm_ps2_mouse()  Likewise
* mouse_moved()  Likewise
* mouse_button()  Likewise
  * i386/i386at/model_dep.c
* i386at_init()  return type void
* timemmap()  return type int
* startrtclock()  return type void
  * i386/i386at/lpr.c
* lprprobe()  return type int
* lpropen()  Likewise
* lprclose()  return type void
* lprread()  return type int
* lprwrite()  Likewise
* lprportdeath()  Likewise
* lprstop()  Likewise
* lprpr()  return type int
* lprpr_addr()  return type void
  * i386/i386/fpu.c
* fpnoextflt()  return type void
* fpextovrflt()  Likewise
* fpexterrflt()  Likewise
* fp_save()  Likewise
* fp_load()  Likewise
* fpintr()  Likewise
  * i386/i386/loose_ends.c
* delay()  return type void
  * i386/i386/phys.c
* pmap_zero_page()  return type void
* pmap_copy_page()  Likewise
* copy_to_phys()  Likewise
* copy_from_phys()  Likewise
  * i386/i386/pic.c
* picinit()  return type void
* form_pic_mask()  Likewise
* intnull()  Likewise
* prtnull()  Likewise
  * i386/i386/pit.c
* clkstart()  return type void
  * i386/intel/pmap.c
* pmap_pageable()  return type void


Thanks,

Barry deFreese (aka bddebian

Re: Gnumach cleanup - 'return type defaults to int'

[Barry deFreese]

- Original Message - 
From: "Barry deFreese" <[EMAIL PROTECTED]>

To: 
Sent: Monday, November 13, 2006 5:39 AM
Subject: Gnumach cleanup - 'return type defaults to int'



As per Samuels request, here is a patch to clean up all warnings for
non-typed functions.




Hi again folks.  Something weird is happening to me with cvs diff.  So if 
someone reviews/commits this, please note that mouseintr() in 
i386/i386at/kd_mouse.c  should be int, NOT void.


Sorry and thanks!

Barry deFreese (aka bddebian) 




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

Gnumach cleanup 5 - Control reaches end of non-void function

[Barry deFreese]

Heya gents,

Just a quick one to clean the remaining warnings in the title.

I realize that this reverts a couple of the things I sent on my last
patch but several of the lpr functions really return nothing so should
have been void in the first place.

Thanks as always,

Barry deFreese (aka bddebian)
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	14 Nov 2006 03:43:31 -
@@ -570,6 +570,7 @@ printf("user trap %d error %d sub %08x\n
 
 	i386_exception(exc, code, subcode);
 	/*NOTREACHED*/
+	return -1;
 }
 
 /*
@@ -1116,6 +1117,8 @@ check_io_fault(regs)
 		/* port not mapped */
 		return FALSE;
 	}
+	/* NOTREACHED ? */
+	return FALSE;
 }
 
 #if	MACH_PCSAMPLE > 0
Index: i386/i386at/com.c
===
RCS file: /cvsroot/hurd/gnumach/i386/i386at/Attic/com.c,v
retrieving revision 1.3.2.4
diff -u -p -r1.3.2.4 com.c
--- i386/i386at/com.c	13 Nov 2006 21:30:36 -	1.3.2.4
+++ i386/i386at/com.c	14 Nov 2006 03:43:31 -
@@ -45,10 +45,10 @@
 
 extern void timeout(), ttrstrt();
 
-int comprobe(), comintr(), comstart(), commctl();
-void comattach();
+int comprobe(), comstart(), commctl();
+void comattach(), comstop(), comintr();
 static void comparam();
-int comstop(), comgetstat(), comsetstat();
+io_return_t comgetstat(), comsetstat();
 
 static vm_offset_t com_std[NCOM] = { 0 };
 struct bus_device *cominfo[NCOM];
@@ -487,7 +487,7 @@ unsigned int	count;
 	return (D_SUCCESS);
 }
 
-int
+void
 comintr(unit)
 int unit;
 {
@@ -807,7 +807,7 @@ commctl(
 	return commodem[unit];
 }
 
-int
+void
 comstop(tp, flags)
 register struct tty *tp;
 int	flags;
Index: i386/i386at/kd.c
===
RCS file: /cvsroot/hurd/gnumach/i386/i386at/Attic/kd.c,v
retrieving revision 1.5.2.11
diff -u -p -r1.5.2.11 kd.c
--- i386/i386at/kd.c	13 Nov 2006 21:30:36 -	1.5.2.11
+++ i386/i386at/kd.c	14 Nov 2006 03:43:32 -
@@ -489,7 +489,7 @@ kdopen(dev, flag, ior)
 	struct 	tty	*tp;
 	int	kdstart();
 	spl_t	o_pri;
-	int	kdstop();
+	void	kdstop();
 
 	tp = &kd_tty;
 	o_pri = spltty();
@@ -1170,7 +1170,7 @@ struct	tty	*tp;
 }
 
 /*ARGSUSED*/
-int
+void
 kdstop(tp, flags)
 	register struct tty *tp;
 	int	flags;
Index: i386/i386at/lpr.c
===
RCS file: /cvsroot/hurd/gnumach/i386/i386at/Attic/lpr.c,v
retrieving revision 1.1.1.1.4.9
diff -u -p -r1.1.1.1.4.9 lpr.c
--- i386/i386at/lpr.c	13 Nov 2006 21:30:36 -	1.1.1.1.4.9
+++ i386/i386at/lpr.c	14 Nov 2006 03:43:32 -
@@ -64,10 +64,11 @@ extern void 	ttrstrt();
  * Driver information for auto-configuration stuff.
  */
 
-int 	lprprobe(), lprintr(), lprstart(), lprstop();
+int 	lprprobe(), lprintr(), lprstart(); 
+void	lprstop();
 void	lprattach(struct bus_device *);
 #ifdef	MACH_KERNEL
-int lprstop(), lprgetstat(), lprsetstat();
+int lprgetstat(), lprsetstat();
 #endif	/* MACH_KERNEL */
 
 struct bus_device *lprinfo[NLPR];	/* ??? */
@@ -369,7 +370,7 @@ struct tty *tp;
 }
 
 #ifdef	MACH_KERNEL
-int
+void
 lprstop(tp, flags)
 register struct tty *tp;
 int	flags;
@@ -378,7 +379,7 @@ int	flags;
 		tp->t_state |= TS_FLUSH;
 }
 #else	/* MACH_KERNEL */
-int lprstop(tp, flag)
+void lprstop(tp, flag)
 struct tty *tp;
 {
 	int s = spltty();
Index: kern/eventcount.c
===
RCS file: /cvsroot/hurd/gnumach/kern/eventcount.c,v
retrieving revision 1.1.1.1.4.6
diff -u -p -r1.1.1.1.4.6 eventcount.c
--- kern/eventcount.c	13 Nov 2006 21:30:37 -	1.1.1.1.4.6
+++ kern/eventcount.c	14 Nov 2006 03:43:33 -
@@ -232,6 +232,7 @@ kern_return_t evc_wait_clear(natural_t e
 	simple_unlock(&ev->lock);
 	splx(s);
 	ret = KERN_NO_SPACE; /* XX */
+	return ret;
 }
 
 /*
Index: util/putchar.c
===
RCS file: /cvsroot/hurd/gnumach/util/Attic/putchar.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 putchar.c
--- util/putchar.c	25 Feb 1997 21:28:35 -	1.1.1.1
+++ util/putchar.c	14 Nov 2006 03:43:35 -
@@ -21,7 +21,7 @@
  *  Author: Bryan Ford, University of Utah CSL
  */
 
-int putchar(int c)
+void putchar(int c)
 {
 	cnputc(c);
 }
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Gnumach cleanup Round 4

[Barry deFreese]

- Original Message - 
From: "Roland McGrath" <[EMAIL PROTECTED]>

To: "Samuel Thibault" <[EMAIL PROTECTED]>
Cc: "Barry deFreese" <[EMAIL PROTECTED]>; 
Sent: Monday, November 13, 2006 7:02 PM
Subject: Re: Gnumach cleanup Round 4



Roland McGrath, le Mon 13 Nov 2006 13:44:30 -0800, a écrit :
> > I don't disagree.  Have a suggestion for a better place to declare 
> > it?

>
> Some machine-independent header included by the relevant code.

kern/model_dep.h then?


If you invent a header, don't give it a silly name like that.
I meant some existing header if there is an appropriate one.



Gents,

In other *nixes it appears to be declared in sys/ddi.h.  Does that make more 
sense?


Thanks,

Barry deFreese (aka bddebian) 




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

Building glibc with TLS

[Barry deFreese]

OK, for kicks I tried to build glibc with --with-tls and --without-__thread 
using my gnumach with the gdt stuff I did a couple weeks ago and Jeroens 
patch from here:


http://www.dekkers.cx/hurd/glibc-tls.patch


Here is what I got:

CPP='gcc-4.0 -E -x c-header' 
/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/elf/ld.so.1 
--library-path 
/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/math:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/elf:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/dlfcn:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/nss:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/nis:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/rt:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/resolv:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/crypt:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/mach:/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/hurd:/X11R6/lib 
/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/sunrpc/rpcgen 
-Y ../scripts -c rpcsvc/bootparam_prot.x -o 
/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/sunrpc/xbootparam_prot.T
make[3]: *** 
[/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/sunrpc/xbootparam_prot.stmp] 
Segmentation fault
make[3]: Leaving directory 
`/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/glibc-2.3.6/sunrpc'

make[2]: *** [sunrpc/others] Error 2
make[2]: Leaving directory 
`/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/glibc-2.3.6'

make[1]: *** [all] Error 2
make[1]: Leaving directory 
`/devel2/bdefreese/glibc_11142006/glibc-2.3.6.ds1/build-tree/hurd-i386-libc'



I'll see if I can play with this but it's probably over my head.

Thanks,

Barry deFreese (aka bddebian) 




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

Gnumach cleanup Round 6

[Barry deFreese]

Hi folks, it's your favorite PITA again.. :-)


 * ddb/db_aout.c  Include: db_output.h
 * ddb/db_break.c  Include:  db_cond.h, db_output.h, and db_expr.h
   * db_delete_cmd():  specify int for variable n
 * ddb/db_command.c  Include:  db_macro.h, db_expr.h, and db_examine.h
 * ddb/db_command.h  Add forward declarations for:
   * db_exec_cmd_nest()
 * ddb/db_cond.c  Include:  db_cond.h, db_expr.h, and db_output.h
   * db_cond_cmd():  specify int for variable c
 * ddb/db_cond.h  New file
 * ddb/db_examine.c  Include:  machine/db_interface.h, 
ddb/db_examine.h, ddb/db_expr.h

   * Remove forward declarations for:  db_strcpy() and db_examine()
   * db_xcdump()  specify int for variables i,n
 * ddb/db_examine.h  New file
 * ddb/db_expr.c  Include: db_expr.h, db_output.h, db_sym.h, db_variables.h
 * ddb/db_input.c  Include: db_command.h
 * ddb/db_input.h  New file
 * ddb/db_lex.c  Include:  db_command.h, db_examine.h, db_input.h, 
db_output.h

   * db_skip_to_eol()  specify int for variables skip, t, n
   * db_lex()  specify int for variable c
 * ddb/db_lex.h  Remove forward declaration for db_lex().
 * ddb/db_macro.c  Include:  db_examine.h, db_expr.h, db_output.h
   * db_def_macro_cmd()  specify int for variables c, n
 * ddb/db_macro.h  New file
 * ddb/db_output.c  Include:  db_command.h
 * ddb/db_output.h  Add forward declaration for db_printf()
 * ddb/db_print.c  Include machine/db_interface.h, ddb/db_command.h, 
ddb/db_output.h

   * db_show_regs()  specify int for variable i
 * ddb/db_run.c  Include: db_command.h, db_examine.h, db_output.h, 
db_watch.h

 * ddb/db_run.h  Include kern/task.h, machine/db_machdep.h
   * Add forward declarations:
 * db_single_step()
 * db_single_step_cmd()
 * db_in_single_step()
 * ddb/db_sym.c  Include:  db_command.h, db_output.h
   * db_sym_parse_and_lookup()  specify int for variable n
 * ddb/db_sym.h  Add forward declaration for db_line_at_pc()
 * ddb/db_task_thread.c  Include:  db_command.h, db_expr.h, db_lex.h, 
db_output.h

   * db_lookup_task()  specify int for variables task_id, npset
   * db_lookup_task_thread()  specify int for variable thread_id
   * db_lookup_thread()  specify int for variables thread_id, ntask, npset
   * db_lookup_task_id()  specify int for variables task_id, npset
   * db_lookup_thread_id()  specify int for variable thread_id
 * ddb/db_trap.c  Include: db_examine.h, db_output.h
 * ddb/db_trap.h  New file
 * ddb/db_variables.c  Include:  db_command.h, db_examine.h, db_expr.h, 
db_output.h

   * db_get_suffix()  specify int for variable value
   * db_cmp_variable_name()  specify int for variable level
 * ddb/db_variables.h  Add forward declaration for db_get_variable()
 * ddb/db_watch.c  db_command.h, db_expr.h, db_output.h, db_run.h
 * ddb/db_write_cmd.c  Include: db_expr.h, db_output.h
 * i386/i386/db_interface.c  Include: kern/printf.h, ddb/db_access.h, 
ddb/db_command.h, ddb/db_output.h, ddb/db_run.h, ddb/db_trap.h

   * kdbprinttrap()  Add void return type to function declaration
   * db_user_to_kernel_address()  specify int for variable *kaddr
   * db_task_name()  specify int for variable n
 * i386/i386/db_interface.h  New file
 * i386/i386/db_trace.c  Add int return type to function declaration 
for db_i386_reg_value()

 * i386/i386/trap.c  Include:  ddb/db_watch.h, ddb/db_run.h
 * ipc/ipc_kmsg.c  Include: ddb/db_output.h if MACH_KDB is defined
 * kern/lock.c  Include: ddb/db_output.h


Thanks!

Barry deFreese (aka bddebian)


Index: ddb/db_aout.c
===
RCS file: /cvsroot/hurd/gnumach/ddb/Attic/db_aout.c,v
retrieving revision 1.2.2.2
diff -u -p -r1.2.2.2 db_aout.c
--- ddb/db_aout.c   8 Nov 2006 01:45:43 -   1.2.2.2
+++ ddb/db_aout.c   15 Nov 2006 17:15:51 -
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include /* data types */
+#include 
 #include 
 
 #ifndefDB_NO_AOUT
Index: ddb/db_break.c
===
RCS file: /cvsroot/hurd/gnumach/ddb/Attic/db_break.c,v
retrieving revision 1.2.2.1
diff -u -p -r1.2.2.1 db_break.c
--- ddb/db_break.c  15 Oct 2006 14:59:03 -  1.2.2.1
+++ ddb/db_break.c  15 Nov 2006 17:15:51 -
@@ -43,6 +43,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #defineNBREAKPOINTS100
 #define NTHREAD_LIST   (NBREAKPOINTS*3)
@@ -594,7 +597,7 @@ db_list_breakpoints()
 void
 db_delete_cmd()
 {
-   register n;
+   register int n;
thread_t thread;
vm_offset_t task_thd;
boolean_t user_global = FALSE;
@@ -677,7 +680,7 @@ db_breakpoint_cmd(addr, have_addr, count
db_expr_t   count;
char *  modif;
 {
-   register n;
+   register int n;
thread_t thread;
boolean_t user_global = db_option(modif, 'U');
boolean_t task_bpt = db_option(modif, 'T')

Re: Maintaining the tool chain

[Barry deFreese]

Thomas Schwinge wrote:

Hello!

I just added an item to ``The GNU Hurd - People at Savannah: Project Help
Wanted'', <http://savannah.gnu.org/people/?group=hurd>:

#v+
``Maintaining the tool chain''

We seek help in keeping the Hurd-specific parts of the GNU tool chain
(mostly GCC, binutils and glibc) up-to-date in an environment where the
tool chain is being advanced for the Linux kernel, as an example, and
subsequently the Hurd-specific parts would need to be adopted to these
advancements.

Please contact us mailing to  if you are interested in
helping here.
#v-


Thanks to Michael Banck for the suggestion to add such a inquiry.


Regards,
 Thomas
  
  

Thomas,

You know I'm game if there is anything my limited skillset can bring to 
the table.


Thanks,

Barry deFreese (aka bddebian)


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

Re: Gnumach cleanup Round 6

[Barry deFreese]

Thomas Bushnell BSG wrote:

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.c11 Nov 2006 00:54:05 -  1.5.2.6
+++ i386/i386/trap.c15 Nov 2006 17:15:58 -
@@ -60,6 +60,8 @@ extern void thread_exception_return();
 extern void i386_exception();
 
 #if	MACH_KDB

+#include 
+#include 
 boolean_t  debug_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

  

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.


Thanks,

Barry


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

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

[Barry deFreese]

Follow-up Comment #2, bug #17346 (project hurd):

This better?

   vm_size_t memsize = boot_info.mem_upper;
 
if ((memsize >= 0x40))
  memsize = (0x40-1);
 
phys_last_addr = 0x10 + (memsize * 0x400);

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[bug #17120] GNU Mach debian dir

[Barry deFreese]

Follow-up Comment #3, bug #17120 (project hurd):

Isn't it standard practice not to include debian dirs in upstream tarballs? 
What's the issue with just removing this?  Thanks.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

Hurd Pthreads

[Barry deFreese]

Heya gang,

OK, I have a HUGE cthreads->pthreads patch going that is going fairly 
well.  However, we still have an issue with hurd_condition_wait.


Can that be stopped-gapped into libpthreads, or should some real glibc 
work be done first?


In other words, am I wasting my time as always?

Thanks!

Barry deFreese (aka bddebian)


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

Re: ``make dist'' and friends

[Barry deFreese]

Thomas Schwinge wrote:

Hello!

This is mainly for Barry, but there is no reason that I should send it
privately, so...


19:49  WTF generates the .defs.c files?

Have a look at the magic in `Makerules.am' and how it is being used in
`Makefrag.am'.  This is not optimal, but I didn't invent a better way so
far.  It's also marked as `TODO' in there.


19:56  OK, I get make dist to run, then configure seems to run clean 
finally on the extracted tarball.  But now when running make, I get:
19:56  ld# make
19:56  make  all-recursive
19:56  make[1]: Entering directory 
`/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build'
19:56  make[2]: Entering directory 
`/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build'
19:56  grep: ../CVS/Root: No such file or directory
19:56  make[2]: *** No rule to make target 
`vm/memory_object_user.user.defs.c', needed by `../ipc/ipc_entry.c'.  Stop.
19:57  make[2]: Leaving directory 
`/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build'
19:57  make[1]: *** [all-recursive] Error 1
19:57  make[1]: Leaving directory 
`/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build'
19:57  make: *** [all] Error 2

I checked in a change to oppress the (harmless) error message from grep.
No action required from your side.

For the actual error message from above, I think I'd need to have a look
at the changes you did so far.


22:19  Why is everything nodist_foo.. in Makefrag.am?

Those are the files that are generated during the build (e.g. mig's
output files) and we thusly don't want to include in a release tarball.


Regards,
 Thomas
  
  

Thomas,

Aye, I have fixed all of those.  Not sure if I've done it the "best" way 
but I have added a few dist_libkernel_a_SOURCE to include all the header 
files, .sym, .srv, and .cli files.


Now I am stuck on one that I cannot figure out:

< i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o
make[2]: *** No rule to make target `i386/i386/i386asm.h', needed by 
`../ipc/ipc_entry.c'.  Stop.



Thanks,

Barry deFreese (aka bddebian)


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

Re: ``make dist'' and friends

[Barry deFreese]

Barry deFreese wrote:

Thomas Schwinge wrote:

Hello!

This is mainly for Barry, but there is no reason that I should send it
privately, so...


19:49  WTF generates the .defs.c files?

Have a look at the magic in `Makerules.am' and how it is being used in
`Makefrag.am'.  This is not optimal, but I didn't invent a better way so
far.  It's also marked as `TODO' in there.


19:56  OK, I get make dist to run, then configure seems to 
run clean finally on the extracted tarball.  But now when running 
make, I get:

19:56  ld# make
19:56  make  all-recursive
19:56  make[1]: Entering directory 
`/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 

19:56  make[2]: Entering directory 
`/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 


19:56  grep: ../CVS/Root: No such file or directory
19:56  make[2]: *** No rule to make target 
`vm/memory_object_user.user.defs.c', needed by `../ipc/ipc_entry.c'.  
Stop.
19:57  make[2]: Leaving directory 
`/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 


19:57  make[1]: *** [all-recursive] Error 1
19:57  make[1]: Leaving directory 
`/devel2/bdefreese/gnumach-1-11272006/gnumach/build/tmp/gnumach-1.3.99/build' 


19:57  make: *** [all] Error 2

I checked in a change to oppress the (harmless) error message from grep.
No action required from your side.

For the actual error message from above, I think I'd need to have a look
at the changes you did so far.


22:19  Why is everything nodist_foo.. in Makefrag.am?

Those are the files that are generated during the build (e.g. mig's
output files) and we thusly don't want to include in a release tarball.


Regards,
 Thomas


Thomas,

Aye, I have fixed all of those.  Not sure if I've done it the "best" 
way but I have added a few dist_libkernel_a_SOURCE to include all the 
header files, .sym, .srv, and .cli files.


Now I am stuck on one that I cannot figure out:

< i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o
make[2]: *** No rule to make target `i386/i386/i386asm.h', needed by 
`../ipc/ipc_entry.c'.  Stop.



Thanks,

Barry deFreese (aka bddebian)

A small update.  Apparently 
i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o isn't getting 
built but I get no error...


Thanks,

Barry


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

Re: [task #5490] syslog

[Barry deFreese]

Constantine Kousoulos wrote:

Hello again,

From http://savannah.gnu.org/task/?5490:
"Find and implement a suitable way to make the Hurd servers use 
`syslog'. "


Can someone explain what this task demands to be done?

Debian's syslogd seems to be working with the current GNU/Hurd 
snapshot. To test it, i added a few syslog entries in /hurd/utils/ps.c 
and it worked ok.


I understand that syslogd cannot act as klogd does in linux. Maybe we 
need to modify GNU Mach or glibc's syslog.h to get something klogi. 
But why can't syslogd work as it is for the hurd servers?



Thanks,
Constantine



Constantine,

AFAIUI, the task IS to make Hurd code write entries to syslog.

Good luck :-)

Barry


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

Re: ``make dist'' and friends

[Barry deFreese]

Thomas Schwinge wrote:

Hello!

On Tue, Nov 28, 2006 at 12:13:20AM -0500, Barry deFreese wrote:
  

Barry deFreese wrote:

[...] I have added a few dist_libkernel_a_SOURCE to include all the 
header files, .sym, .srv, and .cli files.
  


That seems to be correct.  I hope that doing so doesn't break anything.
(Thinking about the rules in `Makerules.am' that deal with those files.)
But you should have noticed if it had...


  

Now I am stuck on one that I cannot figure out:

< i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o
make[2]: *** No rule to make target `i386/i386/i386asm.h', needed by 
`../ipc/ipc_entry.c'.  Stop.
  


Probably some of its dependency files are still missing to be added to
some `*_SOURCE' variable, have a look at the first set of rules in
`Makerules.am'.


  
A small update.  Apparently 
i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o isn't getting 
built but I get no error...



But it's definitely needed, as I understand this at the moment.  (I can't
access a built tree at the moment.)


Regards,
 Thomas
  


OK gang, I've gotten pretty far but now I'm a little confused.  I had to 
include linux/src/drivers/scsi/FlashPoint.c because BusLogic.c 
includes.  But now it is attempting to build FlashPoint.c and failing.


gcc -nostdinc -imacros config.h -Ii386 -I. -I../i386 
-I../i386/include/mach/sa -I../include -D__ASSEMBLY__ -traditional 
-nostdinc -imacros config.h -Ii386 -I. -I../i386 
-I../i386/include/mach/sa -I../include -I../i386/linux/dev/include 
-I./linux/dev/include -I../linux/dev/include -I./linux/src/include 
-I../linux/src/include -g -O2 -c -o 
linux/src/arch/i386/lib/liblinux_a-semaphore.o `test -f 
'linux/src/arch/i386/lib/semaphore.S' || echo 
'../'`linux/src/arch/i386/lib/semaphore.S
if gcc -DHAVE_CONFIG_H -I. -I.. -I.  -nostdinc -imacros config.h -Ii386 
-I. -I../i386 -I../i386/include/mach/sa -I../include 
-I../i386/linux/dev/include -I./linux/dev/include -I../linux/dev/include 
-I./linux/src/include -I../linux/src/include  -O2 -Wall 
-fno-strict-aliasing -g -O2 -MT 
linux/src/drivers/scsi/liblinux_a-FlashPoint.o -MD -MP -MF 
"linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo" -c -o 
linux/src/drivers/scsi/liblinux_a-FlashPoint.o `test -f 
'linux/src/drivers/scsi/FlashPoint.c' || echo 
'../'`linux/src/drivers/scsi/FlashPoint.c; \
   then mv -f 
"linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo" 
"linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Po"; else rm -f 
"linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo"; exit 1; fi
../linux/src/drivers/scsi/FlashPoint.c: In function 
'FlashPoint_ProbeHostAdapter':
../linux/src/drivers/scsi/FlashPoint.c:2432: warning: implicit 
declaration of function 'inb'
../linux/src/drivers/scsi/FlashPoint.c:2467: warning: implicit 
declaration of function 'outb'
../linux/src/drivers/scsi/FlashPoint.c: In function 
'FlashPoint_ReleaseHostAdapter':
../linux/src/drivers/scsi/FlashPoint.c:4106: warning: implicit 
declaration of function 'outl'

../linux/src/drivers/scsi/FlashPoint.c: In function 'FPT_RNVRamData':
../linux/src/drivers/scsi/FlashPoint.c:4146: warning: implicit 
declaration of function 'inl'
../linux/src/drivers/scsi/FlashPoint.c: In function 
'FlashPoint_HandleInterrupt':
../linux/src/drivers/scsi/FlashPoint.c:4713: warning: implicit 
declaration of function 'inw'
../linux/src/drivers/scsi/FlashPoint.c:4730: warning: implicit 
declaration of function 'outw'

../linux/src/drivers/scsi/FlashPoint.c: At top level:
../linux/src/drivers/scsi/FlashPoint.c:12056: error: expected ')' before 
'*' token
../linux/src/drivers/scsi/FlashPoint.c:12063: error: expected '=', ',', 
';', 'asm' or '__attribute__' before 'FlashPoint__HardwareResetHostAdapter'
../linux/src/drivers/scsi/FlashPoint.c:12069: error: expected ')' before 
'CardHandle'
../linux/src/drivers/scsi/FlashPoint.c:12076: error: expected ')' before 
'CardHandle'
../linux/src/drivers/scsi/FlashPoint.c:12083: error: expected ')' before 
'CardHandle'
../linux/src/drivers/scsi/FlashPoint.c:12090: error: expected '=', ',', 
';', 'asm' or '__attribute__' before 'FlashPoint__InterruptPending'
../linux/src/drivers/scsi/FlashPoint.c:12097: error: expected ')' before 
'CardHandle'
../linux/src/drivers/scsi/FlashPoint.c:12117: error: expected ')' before 
'CardHandle'

make[2]: *** [linux/src/drivers/scsi/liblinux_a-FlashPoint.o] Error 1
rm i386/i386/i386asm.symc.o i386/i386/i386asm.symc
make[2]: Leaving directory `/tmp/gnumach-1.3.99/build'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/gnumach-1.3.99/build'
make: *** [all] Error 2


But afaict, in a normal (i.e. not from make dist's tarball), 
FlashPoint.c is not build.  I am attaching a diff of what I have done so 
far.


Thanks!

Barry deFreese (aka bddebian)


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

Re: ``make dist'' and friends

[Barry deFreese]

Barry deFreese wrote:

Thomas Schwinge wrote:

Hello!

On Tue, Nov 28, 2006 at 12:13:20AM -0500, Barry deFreese wrote:
 

Barry deFreese wrote:
   
[...] I have added a few dist_libkernel_a_SOURCE to include all the 
header files, .sym, .srv, and .cli files.
  


That seems to be correct.  I hope that doing so doesn't break anything.
(Thinking about the rules in `Makerules.am' that deal with those files.)
But you should have noticed if it had...


 

Now I am stuck on one that I cannot figure out:

< i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o
make[2]: *** No rule to make target `i386/i386/i386asm.h', needed 
by `../ipc/ipc_entry.c'.  Stop.
  


Probably some of its dependency files are still missing to be added to
some `*_SOURCE' variable, have a look at the first set of rules in
`Makerules.am'.


 
A small update.  Apparently 
i386/i386/lib_dep_tr_for_defs_a-mach_i386.server.defs.o isn't 
getting built but I get no error...



But it's definitely needed, as I understand this at the moment.  (I 
can't

access a built tree at the moment.)


Regards,
 Thomas
  


OK gang, I've gotten pretty far but now I'm a little confused.  I had 
to include linux/src/drivers/scsi/FlashPoint.c because BusLogic.c 
includes.  But now it is attempting to build FlashPoint.c and failing.


gcc -nostdinc -imacros config.h -Ii386 -I. -I../i386 
-I../i386/include/mach/sa -I../include -D__ASSEMBLY__ -traditional 
-nostdinc -imacros config.h -Ii386 -I. -I../i386 
-I../i386/include/mach/sa -I../include -I../i386/linux/dev/include 
-I./linux/dev/include -I../linux/dev/include -I./linux/src/include 
-I../linux/src/include -g -O2 -c -o 
linux/src/arch/i386/lib/liblinux_a-semaphore.o `test -f 
'linux/src/arch/i386/lib/semaphore.S' || echo 
'../'`linux/src/arch/i386/lib/semaphore.S
if gcc -DHAVE_CONFIG_H -I. -I.. -I.  -nostdinc -imacros config.h 
-Ii386 -I. -I../i386 -I../i386/include/mach/sa -I../include 
-I../i386/linux/dev/include -I./linux/dev/include 
-I../linux/dev/include -I./linux/src/include -I../linux/src/include  
-O2 -Wall -fno-strict-aliasing -g -O2 -MT 
linux/src/drivers/scsi/liblinux_a-FlashPoint.o -MD -MP -MF 
"linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo" -c -o 
linux/src/drivers/scsi/liblinux_a-FlashPoint.o `test -f 
'linux/src/drivers/scsi/FlashPoint.c' || echo 
'../'`linux/src/drivers/scsi/FlashPoint.c; \
   then mv -f 
"linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo" 
"linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Po"; else rm -f 
"linux/src/drivers/scsi/.deps/liblinux_a-FlashPoint.Tpo"; exit 1; fi
../linux/src/drivers/scsi/FlashPoint.c: In function 
'FlashPoint_ProbeHostAdapter':
../linux/src/drivers/scsi/FlashPoint.c:2432: warning: implicit 
declaration of function 'inb'
../linux/src/drivers/scsi/FlashPoint.c:2467: warning: implicit 
declaration of function 'outb'
../linux/src/drivers/scsi/FlashPoint.c: In function 
'FlashPoint_ReleaseHostAdapter':
../linux/src/drivers/scsi/FlashPoint.c:4106: warning: implicit 
declaration of function 'outl'

../linux/src/drivers/scsi/FlashPoint.c: In function 'FPT_RNVRamData':
../linux/src/drivers/scsi/FlashPoint.c:4146: warning: implicit 
declaration of function 'inl'
../linux/src/drivers/scsi/FlashPoint.c: In function 
'FlashPoint_HandleInterrupt':
../linux/src/drivers/scsi/FlashPoint.c:4713: warning: implicit 
declaration of function 'inw'
../linux/src/drivers/scsi/FlashPoint.c:4730: warning: implicit 
declaration of function 'outw'

../linux/src/drivers/scsi/FlashPoint.c: At top level:
../linux/src/drivers/scsi/FlashPoint.c:12056: error: expected ')' 
before '*' token
../linux/src/drivers/scsi/FlashPoint.c:12063: error: expected '=', 
',', ';', 'asm' or '__attribute__' before 
'FlashPoint__HardwareResetHostAdapter'
../linux/src/drivers/scsi/FlashPoint.c:12069: error: expected ')' 
before 'CardHandle'
../linux/src/drivers/scsi/FlashPoint.c:12076: error: expected ')' 
before 'CardHandle'
../linux/src/drivers/scsi/FlashPoint.c:12083: error: expected ')' 
before 'CardHandle'
../linux/src/drivers/scsi/FlashPoint.c:12090: error: expected '=', 
',', ';', 'asm' or '__attribute__' before 'FlashPoint__InterruptPending'
../linux/src/drivers/scsi/FlashPoint.c:12097: error: expected ')' 
before 'CardHandle'
../linux/src/drivers/scsi/FlashPoint.c:12117: error: expected ')' 
before 'CardHandle'

make[2]: *** [linux/src/drivers/scsi/liblinux_a-FlashPoint.o] Error 1
rm i386/i386/i386asm.symc.o i386/i386/i386asm.symc
make[2]: Leaving directory `/tmp/gnumach-1.3.99/build

Re: ``make dist'' and friends

[Barry deFreese]

That seems to be correct.  I hope that doing so doesn't break anything.
(Thinking about the rules in `Makerules.am' that deal with those files.)
But you should have noticed if it had...



I decided to add the `.srv' and `.cli' files to `EXTRA_DIST' instead.


  
OK gang, I've gotten pretty far but now I'm a little confused.  I had 
to include linux/src/drivers/scsi/FlashPoint.c because BusLogic.c 
includes.  But now it is attempting to build FlashPoint.c and failing.


[...]

But afaict, in a normal (i.e. not from make dist's tarball), 
FlashPoint.c is not build.
  


Correct.

  

Also, I meant to mention.  I suppose one way around this may be to add
FlashPoint.c to EXTRA_DIST instead of inside of a
dist_liblinux_a_SOURCES target?



Correct.  This and similar other files should also be added to
`EXTRA_DIST' instead of some `*_SOURCES'.


  

I am attaching a diff of what I have done so far.
  


Barry, thanks for the patch, it was of great help!

I integrated it into a local tree here at home, changed and added some
bits, began testing it to eventually commit it into the cvs repository,
but before I was able to finish the testing, I hit another Automake bug,
I believe, which I then reported to .  So we now
have to wait until that is resolved.


Regards,
 Thomas
  


Thomas,

Great thanks.  It's funny, I originally had all the .cli and .srv files 
in EXTRA_DIST.. Doh.


So, should I pretty much stop working on this at this point?

Thanks again!

Barry


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

Re: Moving `migcom' out of `[exec_prefix]/libexec/'

[Barry deFreese]

ot;);
printf("\t-user \n");
printf("\t\tName the user-side file \n");
printf("\t-server \n");
printf("\t\tName the server-side file \n");
printf("\t-header \n");
printf("\t\tName the user-side header file \n");
printf("\t-iheader ");
printf("\t\tName the user-side internal header file \n");
printf("\t-sheader \n");
printf("\t\tNAme the server-side header file \n");
printf("\nReport bugs to [EMAIL PROTECTED]");
exit(0);
}

if (PrintVersion)
{
printf("GNU MiG 1.3\n");
printf("Copyright (C) 1989, 1991 Free Software Foundation, Inc.\n");
printf(" Everyone is permitted to copy and distribute verbatim copies of 
this license document, but changing it is not allowed.\n");
exit(0);
}

init_global();
init_type();

LookNormal();
(void) yyparse();

if (errors > 0)
exit(1);

more_global();

uheader = myfopen(UserHeaderFileName, "w");
if (!UserFilePrefix)
user = myfopen(UserFileName, "w");
server = myfopen(ServerFileName, "w");
if (ServerHeaderFileName)
sheader = myfopen(ServerHeaderFileName, "w");
if (IsKernelServer)
{
iheader = myfopen(InternalHeaderFileName, "w");
}

if (BeVerbose)
{
printf("Writing %s ... ", UserHeaderFileName);
fflush(stdout);
}
WriteUserHeader(uheader, StatementList);
myfclose(uheader, UserHeaderFileName);
if (ServerHeaderFileName)
{
if (BeVerbose)
{
printf ("done.\nWriting %s ...", ServerHeaderFileName);
fflush (stdout);
}
WriteServerHeader(sheader, StatementList);
myfclose(sheader, ServerHeaderFileName);
}
if (IsKernelServer)
{
if (BeVerbose)
{
printf("done.\nWriting %s ... ", InternalHeaderFileName);
fflush(stdout);
}
WriteInternalHeader(iheader, StatementList);
myfclose(iheader, InternalHeaderFileName);
}
if (UserFilePrefix)
{
if (BeVerbose)
{
printf("done.\nWriting individual user files ... ");
    fflush(stdout);
}
WriteUserIndividual(StatementList);
}
else
{
if (BeVerbose)
{
printf("done.\nWriting %s ... ", UserFileName);
fflush(stdout);
}
WriteUser(user, StatementList);
myfclose(user, UserFileName);
}
if (BeVerbose)
{
printf("done.\nWriting %s ... ", ServerFileName);
fflush(stdout);
}
WriteServer(server, StatementList);
myfclose(server, ServerFileName);

if (RoutineListFileName != strNULL)
  {
FILE *listfile = myfopen (RoutineListFileName, "w");
WriteRoutineList (listfile, StatementList);
myfclose (listfile, RoutineListFileName);
  }

if (BeVerbose)
printf("done.\n");

return 0;
}

static FILE *
myfopen(const char *name, const char *mode)
{
const char *realname;
FILE *file;
extern int errno;

if (name == strNULL)
realname = "/dev/null";
else
realname = name;

file = fopen(realname, mode);
if (file == NULL)
fatal("fopen(%s): %s", realname, unix_error_string(errno));

return file;
}

static void
myfclose(FILE *file, const char *name)
{
if (ferror(file) || fclose(file))
fatal("fclose(): ", name, unix_error_string(errno));
}
  



  

Constantine,

I'm speaking out of my ass as usual but I assume he suggested Ben 
because we would prefer using argp and Ben is the argp master.  But what 
you have looks reasonable.


Thanks,

Barry deFreese (aka bddebian)


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

[task #5723] Investigate flick

[Barry deFreese]

Follow-up Comment #1, task #5723 (project hurd):

I have done some research and talked to a few people (including Jeff Bailey)
and as far as I can find out Flick is slower and even less maintained than
MiG so I'm not sure what this would buy us?

Thanks.

Barry

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[bug #15329] exec doesn't like zip'ed binaries

[Barry deFreese]

Follow-up Comment #2, bug #15329 (project hurd):

Did Andrew's patch not get committed?  If so, can this bug be closed?  If
not, can it be committed?  Thanks!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[bug #18015] GNU Mach: `make dist' and friends

[Barry deFreese]

Follow-up Comment #2, bug #18015 (project hurd):

Thomas,

Building out of the tree doesn't seem to work for me.

build/../configure works OK but make dist seems to just keep running aclocal,
autoconf, and automake recursively.

Thanks,

Barry

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[bug #18015] GNU Mach: `make dist' and friends

[Barry deFreese]

Follow-up Comment #3, bug #18015 (project hurd):

As usual I screwed up.  It appears I was having a timestamp problem.  "make
dist" works fine and a build on the resulting tarball is fine.  I also tried
running 'make distcheck' which seemed to be working fine but my machine hung
again.  I may try it again and report back.

Thanks,

Barry

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

[bug #18015] GNU Mach: `make dist' and friends

[Barry deFreese]

Follow-up Comment #4, bug #18015 (project hurd):

OK 'make distcheck' did not finish successfully:

rm -f Makefile
ERROR: files left in build directory after distclean:
./config.status.orig
./Makefile.orig
make[1]: *** [distcleancheck] Error 1
make[1]: Leaving directory
`/devel2/bdefreese/gnumach-1-11302006/gnumach/build/gnumach-1.3.99/_build'
make: *** [distcheck] Error 2
rm i386/i386/i386asm.symc.o i386/i386/i386asm.symc


Thanks.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

Building glibc from CVS

[Barry deFreese]

Heya gang,

I am trying to build glibc from CVS and am getting the following error:

In file included from ../include/link.h:47,
from ../include/dlfcn.h:3,
from ../sysdeps/generic/ldsodefs.h:32,
from ../sysdeps/mach/hurd/i386/init-first.c:32:
../sysdeps/generic/rtld-lowlevel.h:1:2: error: #error "Lowlevel 
primitives for ld.so not implemented"

In file included from ../include/dlfcn.h:3,
from ../sysdeps/generic/ldsodefs.h:32,
from ../sysdeps/mach/hurd/i386/init-first.c:32:
../include/link.h:224: error: expected specifier-qualifier-list before 
'__rtld_mrlock_define'

In file included from ../sysdeps/generic/ldsodefs.h:41,
from ../sysdeps/mach/hurd/i386/init-first.c:32:
../sysdeps/generic/rtld-lowlevel.h:1:2: error: #error "Lowlevel 
primitives for ld.so not implemented"



Should we have an rtld-lowlevel.h (I don't see one on any other archs), 
or should we be implementing a sysdep dependent ldsodefs.h instead of 
using generic/?


Thanks!

Barry deFreese (aka bddebian)


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

Re: [bug #18015] GNU Mach: `make dist' and friends

[Barry deFreese]

Thomas Schwinge wrote:

Follow-up Comment #5, bug #18015 (project hurd):

  

ERROR: files left in build directory after distclean:
./config.status.orig
./Makefile.orig



If you add ``DISTCLEANFILES = Makefile.orig config.status.orig'' to
`Makefile.am', does it work then?

  

Thomas,

Sure does:


gnumach-1.3.99 archives ready for distribution:
gnumach-1.3.99.tar.gz

rm i386/i386/i386asm.symc.o i386/i386/i386asm.symc
goober:/devel2/bdefreese/gnumach-1-12032006/gnumach/build#


Thanks,

Barry


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

gcc-4.1 with fastmath

[Barry deFreese]

Heya gang,

I was able to build gcc-4.1 with a crtfastmath.o by changing config.gcc 
to the following:


i[34567]86-*-gnu*)
   tmake_file="${tmake_file} i386/t-crtfm"
   ;;

But when running the attached test code compiled with --fast-math, I get 
the following:


Starting program: /devel/bdefreese/fastmath_test/test1

Program received signal SIGILL, Illegal instruction.
set_fast_math () at ../../src/gcc/config/i386/crtfastmath.c:71
71unsigned int mxcsr = __builtin_ia32_stmxcsr ();
(gdb) bt full
#0  set_fast_math () at ../../src/gcc/config/i386/crtfastmath.c:71
   mxcsr = 16998664
   eax = 1667
   ebx = 
   ecx = 
   edx = 58980863
#1  0x08048855 in __do_global_ctors_aux ()
No symbol table info available.
#2  0x080483dd in _init ()
No symbol table info available.
#3  0x0804868f in __libc_csu_init ()
No symbol table info available.
#4  0x01068edb in __libc_start_main () from /lib/libc.so.0.3
No symbol table info available.
#5  0x08048491 in _start () at ../sysdeps/i386/elf/start.S:119
No locals.



Thanks,

Barry deFreese (aka bddebian)


#include 
#include 
#include 

#define ITERATIONS 1024

typedef struct {
char sign;
long frac;
int exp;
} sdouble;

/* Warning : double's size is hardcoded here, very bad habit. This program
   is initially designed to only run on Itanium. */
sdouble cut_double (double d) {
sdouble ret;
long *db;

db = (long *)&d;

ret.sign = (*db >> 63) & 0x0001;
ret.exp  = ((*db >> 52) & 0x07FF) - 1023;
ret.frac = (*db )  & 0x000F;

return ret;
}

int main (int argc, char **argv) {
sdouble sa;
double a;
int i;

a = 1;
i = 1;

openlog ("double_test", LOG_CONS, LOG_USER);

syslog (LOG_USER | LOG_NOTICE, "starting");

while (i <= ITERATIONS) {
syslog (LOG_USER | LOG_NOTICE, "iteration #%d", i);
a /= 2;
sa = cut_double (a);
printf ("iteration %d : a=(%d, %lx, %d) : ", i, sa.sign,
sa.frac, sa.exp);
printf ("\n");
i++;
}

exit (0);
}
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [bug #18217] glibc: `__libc_once'

[Barry deFreese]

Thomas Schwinge wrote:

Follow-up Comment #2, bug #18217 (project hurd):

Roland: ``Uli abused the macros.  To support the use he wants, __libc_once
should be revamped in all its implementations to return a value or have a
variant that does (value says whether fn just ran).''

  

Is there any reason this wouldn't work?

Current code:

/* Use mutexes as once control variables. */

struct __libc_once
 {
   __libc_lock_t lock;
   int done;
 };

#define __libc_once_define(CLASS,NAME) \
 CLASS struct __libc_once NAME = { MUTEX_INITIALIZER, 0 }

/* Call handler iff the first call.  */
#define __libc_once(ONCE_CONTROL, INIT_FUNCTION) \
 do 
{\
   __libc_lock_lock 
(ONCE_CONTROL.lock); \
   if 
(!ONCE_CONTROL.done)   \
 (INIT_FUNCTION) 
(); \
   ONCE_CONTROL.done = 
1;\
   __libc_lock_unlock 
(ONCE_CONTROL.lock);   \

 } while (0)

Change to:

*Remove struct

#define __libc_once_define(CLASS,NAME) \
   CLASS int NAME = MUTEX_INITIALIZER

/* Call handler iff the first call.  */
#define __libc_once(ONCE_CONTROL, INIT_FUNCTION) \
   do {
 __libc_lock_lock(ONCE_CONTROL);
 if ((ONCE_CONTROL) == MUTEX_INITIALIZER)
   (INIT_FUNCTION)();
 ONCE_CONTROL = 1;
 __libc_lock_unlock(ONCE_CONTROL);
   } while (0)

Or am I waaay off as usual?

Thanks!

Barry deFreese (aka bddebian)



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

Re: [bug #18217] glibc: `__libc_once'

[Barry deFreese]

Roland McGrath wrote:

does not make sense
  


Damn, I figured it didn't.  Do we really need locking here or can we do 
without until we can implement nptl?


Thanks!

Barry


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