ChangeLog entries (was: [patch] ISA-support in GNU Mach PCMCIA core)

2006-09-19 Thread Thomas Schwinge 
Hello!

On Tue, Sep 19, 2006 at 12:58:25AM +0200, Michael Banck wrote:
> On Mon, Sep 18, 2006 at 09:37:05PM +0200, Thomas Schwinge wrote:
> > * i386/linux/configure: Regenerate.
> > * i386/linux/device-drivers.h.in: Likewise.
> > 
> > * i386/linux/configure.ac (AC_PCMCIA_OPTION): New function.
> 
> I thought one mentiones the configure: Regenerate after what prompted
> the regeneration in the first place.

Here is my version:

ChangeLog entries that have an empty line between them are independent of
each other.  (I admit that one could argue whether regenerating a
compiled file is independent of changing its source file or not, but in
my book it is.)  Now, you change such a source file --- configure.ac ---
and commit that change.

#v+
[Date.]  [Who.]  [Where.]

* configure.ac: Foo.
#v-

Afterwards you regenerate the compiled file --- configure --- and commit
that change.  Then the ChangeLog looks like this:

#v+
[Date.]  [Who.]  [Where.]

* configure: Regenerate.

* configure.ac: Foo.
#v-

Of course, committing the whole lot directly as...

#v+
[Date.]  [Who.]  [Where.]

* configure.ac: Foo.
* configure: Regenerate.
#v-

... wouldn't be wrong either, but as I said, I don't know if the files's
time stamps will be alright then.


> Don't know whether the GCS have anything to say on this, though.

.

``6.8.1 Change Log Concepts

You can think of the change log as a conceptual ???undo list??? which
explains how earlier versions were different from the current version.

[...]

6.8.2 Style of Change Logs

[...]

Separate unrelated change log entries with blank lines. When two entries
represent parts of the same change, so that they work together, then
don't put blank lines between them.''


Regards,
 Thomas


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

Locating mis-compilations (was: [bug #17338] GNU Mach vs. GCC 4.1)

2006-09-19 Thread Thomas Schwinge 
Hello!

On Mon, Aug 07, 2006 at 06:27:11AM +0200, Samuel Thibault wrote:
> GCC gets smarter and smarter...  When seeing this:
> 
> [...]

As there seems to be general interest: can you explain what techniques
and tools you used to locate that problem?

elfutils's elfcmp?  objdump with shell script hackery?  Just reading the
source code?  Pure chance?


Regards,
 Thomas


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

Re: Announcing the slow burial of the Hurd Wiki

2006-09-19 Thread Thomas Schwinge 
Hello!

Sorry, still no real news, but...

On Thu, Aug 10, 2006 at 03:04:34AM +0200, Marc Dequ??nes wrote:
> Marc Dequ??nes (Duck) <[EMAIL PROTECTED]> writes:
> 
> > Thomas, anything decided yet ? Do you need an hosting place ? If so,
> > DuckCorp could help in this area.

I will get back to that in case it's needed.


> > > [hurd.gnufans.org]
> >
> > Arf, this domain name is nice. I could sponsor the fee if needed.

I have no particular feeling about keping or dropping that domain name.


> Anything new ? Anything decided ?

Thoughts are going into the direction of having a general GNU wiki.  But
I need more time to think about that, evaluate a lot of different issues,
set up a testing environment, etc.

Can we continue to use the existing wiki until then?


Regards,
 Thomas


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

Re: Locating mis-compilations (was: [bug #17338] GNU Mach vs. GCC 4.1)

2006-09-19 Thread Samuel Thibault 
Hi,

Thomas Schwinge, le Tue 19 Sep 2006 12:47:35 +0200, a écrit :
> On Mon, Aug 07, 2006 at 06:27:11AM +0200, Samuel Thibault wrote:
> > GCC gets smarter and smarter...  When seeing this:
> > 
> > [...]
> 
> As there seems to be general interest: can you explain what techniques
> and tools you used to locate that problem?
> 
> elfutils's elfcmp?  objdump with shell script hackery?  Just reading the
> source code?  Pure chance?

Just like the de4x5 probe hangup: inserting things like
* (unsigned long*) 0xb8000 = 'A';
and
* (unsigned long*) 0xb8000 = 'B';
etc. spread around the kernel (+ some while(1); if the symptom is a
systematic machine reboot) and by dichotomy I could find that the
problem was gdt_init. I had it print the values, found them correct, so
as last resort, run gdb kernel, disassemble gdt_init, and then found out
the optimization.

Samuel


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

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

2006-09-19 Thread Thomas Schwinge 
Hello!

What are people's feelings about having all (working) device drivers
enabled by default when configuring GNU Mach?

The only situations where this is _not_ what I'd expect from a kernel's
build system by default is when a) hunting bugs or b) building a large
number of kernels when testing specific issues (and you then only want to
compile the actually needed device drivers to save time).  Are a) and b)
relevant to justify _not_ having the whole lot enabled by default?


Regards,
 Thomas


signature.asc
Description: Digital signature
___
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?

2006-09-19 Thread Richard Braun 
On Tue, Sep 19, 2006 at 02:37:50PM +0200, Thomas Schwinge wrote:
> What are people's feelings about having all (working) device drivers
> enabled by default when configuring GNU Mach?

I don't like this idea at all :-/. When people build their own kernel,
they usually know what they need. Building all these drivers takes time
(and we all know it matters on the Hurd). The only relevant case which
enables all drivers I could see is the Debian package, which is for
everyone. I think this way (the current way) is a good one and we should
not change it.

-- 
Richard Braun


signature.asc
Description: Digital signature
___
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?

2006-09-19 Thread Michael Banck 
On Tue, Sep 19, 2006 at 02:37:50PM +0200, Thomas Schwinge wrote:
> What are people's feelings about having all (working) device drivers
> enabled by default when configuring GNU Mach?

What would happen if a user configures with --enable-ide?  Would that
mean it only enables ide, or would it be a no-op (or be removed?)

The problem I see is with potential IRQ sharing issues we still have.
AIUI, recompiling gnumach with minimal drivers might resolve those
issues in specific cases.


Michael


___
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?

2006-09-19 Thread Samuel Thibault 
Thomas Schwinge, le Tue 19 Sep 2006 14:37:50 +0200, a écrit :
> What are people's feelings about having all (working) device drivers
> enabled by default when configuring GNU Mach?

That would avoid debian's --enable-this --enable-that ... configuration
line :)

That said, if I want to only enable the drivers I want, I wouldn't like
to have to say --disable-this --disable-that ... either.

Maybe keeping the defaults as they are, and having a --enable-working
option would meet everybody's need?

Samuel


___
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?

2006-09-19 Thread Thomas Schwinge 
Hello!

On Tue, Sep 19, 2006 at 02:37:50PM +0200, Thomas Schwinge wrote:
> What are people's feelings about having all (working) device drivers
> enabled by default when configuring GNU Mach?

Michael, Richard, Samuel: thanks for the quick input.  I can understand
your concerns and would like to propose adding the following to the
configure options:

#v+
  --disable-default-device-drivers
  have all device drivers disabled that can be
  disabled and would otherwise have been enabled by
  default; then use the `--enable-*' options to enable
  only those you actually want to have enabled
#v-

Does that sound alright?


Another issue: I intend to remove all the device driver name aliases from
i386/linux/configure, for example morph...

#v+
[...]
  --enable-de100  enable driver alias de100 for depca
  --enable-de101  enable driver alias de101 for depca
  --enable-de200  enable driver alias de200 for depca
  --enable-de201  enable driver alias de201 for depca
  --enable-de202  enable driver alias de202 for depca
  --enable-de210  enable driver alias de210 for depca
  --enable-de422  enable driver alias de422 for depca
[...]
  --enable-depca  enable driver depca
[...]
#v-

... into...

#v+
[...]
  --enable-depca  enable driver depca (de100, de101, de200, de201,
  de202, de210, de422)
[...]
#v-

Any comments or objections with respect to that?


Regards,
 Thomas


signature.asc
Description: Digital signature
___
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?

2006-09-19 Thread Richard Braun 
On Tue, Sep 19, 2006 at 03:28:38PM +0200, Thomas Schwinge wrote:
> Michael, Richard, Samuel: thanks for the quick input.  I can understand
> your concerns and would like to propose adding the following to the
> configure options:
> 
> #v+
>   --disable-default-device-drivers
>   have all device drivers disabled that can be
>   disabled and would otherwise have been enabled by
>   default; then use the `--enable-*' options to enable
>   only those you actually want to have enabled
> #v-
> 
> Does that sound alright?

AIUI, using this option allows us to build GNU Mach as we do now.
If that's correct, then I don't mind such a change.

> Another issue: I intend to remove all the device driver name aliases from
> i386/linux/configure, for example morph...

[...]

> Any comments or objections with respect to that?

No, it's fine.

-- 
Richard Braun


signature.asc
Description: Digital signature
___
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?

2006-09-19 Thread 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

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

2006-09-19 Thread Michael Banck 
On Tue, Sep 19, 2006 at 09:43:55AM -0400, Barry deFreese wrote:
> How about we move all the drive into userspace? ;-)

Send patches.


Michael


___
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?

2006-09-19 Thread Thomas Bushnell BSG 
Thomas Schwinge <[EMAIL PROTECTED]> writes:

> The only situations where this is _not_ what I'd expect from a kernel's
> build system by default is when a) hunting bugs or b) building a large
> number of kernels when testing specific issues (and you then only want to
> compile the actually needed device drivers to save time).  Are a) and b)
> relevant to justify _not_ having the whole lot enabled by default?

There are also lots of cases historically where two drivers both work,
but are incompatible and cannot coexist together.  Sometimes these
interactions are tricky.

Also, drivers often have delays while waiting for devices to respond
(manufacturer specs often call for things like a *one second* delay
wait) and so booting can take a long time while you wait for a bunch
of nonexistent devices not to respond.

Thomas



___
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

2006-09-19 Thread Barry deFreese 

URL:
  

 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


___

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: GNU Mach: enabling all (working) device drivers by default?

2006-09-19 Thread Thomas Schwinge 
Hello!

On Tue, Sep 19, 2006 at 02:37:50PM +0200, I wrote:
> What are people's feelings about having all (working) device drivers
> enabled by default when configuring GNU Mach?

I just committed the following to gnumach-1-branch:

#v+
2006-09-20  Thomas Schwinge  <[EMAIL PROTECTED]>

* Drivers.macros (AC_DRIVER_ALIAS): Remove definition.
(AC_DRIVER): Extend to take a `description' parameter and consider
`$enable_default_device_drivers'.
(AC_DRIVER_nodef): New definition.
* configure.in (options kdb, kmsg): Remove redundancy.
* i386/configure.in (option default-device-drivers): New option.
(option lpr): Consider `$enable_default_device_drivers'.
* i386/linux/configure.ac: Rework substantially.  Remove all aliases.
Rename some of the device driver options.
(option default-device-drivers): New option.
(linux_DRIVER): Take care about a `description' parameter and don't
invoke AC_DRIVER_ALIAS.
(linux_DRIVER_nodef): New definition.
Adopt all usages of AC_DRIVER and linux_DRIVER to provide a
`description' parameter.
(g_NCR5380, NCR53c406a, eata_dma, wavelan, atp): Change from AC_DRIVER
to AC_DRIVER_nodef to have these device drivers disabled by default.
* doc/mach.texi: Add a note about the outdatedness to the configuration
option table.
* i386/README-Drivers: Update.
#v-

If you are building GNU Mach kernels from gnumach-1-branch, this means
that you a) can now get a usable GNU Mach kernel configuring it just like
`./configure' and b) should now re-visit the file
[GNU Mach]/i386/README-Drivers and the output of `[GNU Mach]/configure
--help=recursive'.


I don't think that I broke something, but who can be sure these days...
Speak up in case.


Regards,
 Thomas


signature.asc
Description: Digital signature
___
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?

2006-09-19 Thread Thomas Schwinge 
Hello again!

On Wed, Sep 20, 2006 at 01:21:52AM +0200, I wrote:
> If you are building GNU Mach kernels from gnumach-1-branch, this means
> that you a) can now get a usable GNU Mach kernel configuring it just like
> `./configure'

I should add that this will select those device drivers by default that
prove to be useful / stable / non-interfering for most people: the ones
that have been selected in the Debian gnumach package for years.

> and b) should now re-visit the file [GNU Mach]/i386/README-Drivers and
> the output of `[GNU Mach]/configure --help=recursive'.

And here I should add that you will notice that I also removed all the
aliases for the device drivers but in turn improved the output of
configure's help screens.


Regards,
 Thomas


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