Hi,
On 1/29/06, Marco Gerards <[EMAIL PROTECTED]> wrote:
> That is weird. I always thought that for compatibility reasons IRQs
> are always <16. In case the OS supports more than 16 IRQs, the OS can
> change the IRQs to prevent shared IRQs. With your NIC this is not the
> case, is this a BIOS b
Hi,
Thomas Schwinge, le Thu 26 Jan 2006 09:36:25 -0500, a écrit :
> On Sat, Jul 30, 2005 at 01:25:47PM +0200, Samuel Thibault wrote:
> > 2005-07-30 Samuel Thibault <[EMAIL PROTECTED]>
> >
> > * irq.c (linux_intr): Disable interrupts when the driver
> > requested it through request_irq()
Gianluca Guida <[EMAIL PROTECTED]> writes:
Hi Gianluca,
> My laptop's motherboard set its RTL8139 NIC IRQ at a value that is not
> included in the range 0<=x<16 and it's not 255.
That is weird. I always thought that for compatibility reasons IRQs
are always <16. In case the OS supports more th
> ./configure --prefix='$(libexecdir)/foo' --libexecdir=/foo
Do you really consider that as a valid use case? Putting
libexecdir's files into `/foo/' and everything else into
`/foo/foo/{bin,share,...}/'?
Yes, I have ended up using similar hacks on several occassions.
If this real
On Sun, Jan 29, 2006 at 06:46:35PM +0100, Alfred M. Szmidt wrote:
>Yes, as long as we don't let the build system create Makefiles in
>subdirectories, which we don't at the moment. Changed.
>
> Would be better to simply stop using manually maintained .in's, and
> use automake, then one won
On Sun, Jan 29, 2006 at 06:46:35PM +0100, Alfred M. Szmidt wrote:
> ./configure --prefix='$(libexecdir)/foo' --libexecdir=/foo
Do you really consider that as a valid use case? Putting libexecdir's
files into `/foo/' and everything else into `/foo/foo/{bin,share,...}/'?
If this really bothers you
> You removed libexecdir (and maybe some other variables), why?
> Doing something like `--prefix=$(libexecdir)/foo' is always OK.
> All variables that can be substituted should be listed. The
> variables also get partially expanded, so that is one more reason
> to list all of them (
On Sun, Jan 29, 2006 at 12:39:57PM +0100, Alfred M. Szmidt wrote:
>2006-01-28 Thomas Schwinge <[EMAIL PROTECTED]>
>
> * Makefile.in: Various cleanups. Do not include $(sysdep)/Makefrag
> anymore. Move shared and system dependent stuff out of this file.
> Include
On Sun, Jan 29, 2006 at 04:28:23PM +0100, Alfred M. Szmidt wrote:
> I don't know what the procedure to include a patch in Linux is. If
> there are some problems including the patch (copyright, functionality,
> ...) then this is up to the maintainers of Linux to point out. I
> think there is no ha
I am subscribed to the list. No need to send the messages to me in
private unless you are in a hurry, since gnu servers seem to be
late these days. :-)
It is normal to CC all people whom you reply to on a mailing list.
However, the modifications are not made properly by GPL2 (includi
On Sun, Jan 29, 2006 at 12:42:22PM +0100, Alfred M. Szmidt wrote:
> It would be a pitty if users had to recompile their kernel to have
> this supported, is there any possibility of including this in Linux?
I hope Roland will submit this upstream once this has been tested a bit
more. I will roll D
On Sun, Jan 29, 2006 at 12:42:22PM +0100, Alfred M. Szmidt wrote:
> It would be a pitty if users had to recompile their kernel to have
> this supported, is there any possibility of including this in Linux?
I am subscribed to the list. No need to send the messages to me in
private unless you are in
It would be a pitty if users had to recompile their kernel to have
this supported, is there any possibility of including this in Linux?
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
2006-01-28 Thomas Schwinge <[EMAIL PROTECTED]>
* Makefile.in: Various cleanups. Do not include $(sysdep)/Makefrag
anymore. Move shared and system dependent stuff out of this file.
Include Makerules.
This says nothing about what actually changed. `Did stuff
On Sat, Sep 10, 2005 at 11:01:22PM +0200, I wrote:
> [...]
> The problem is basically that the whole build is driven by the
> "all-architectures" Makefile, which doen't know about the architecture
> specific configure options, which `--enable-lpr' is (the only one,
> though).
>
> Fixing that issu
A fixed patch for supporting passive translators in Linux follows.
This is a simple fix of the latest Roland's patch. Since I fixed the
patch by hand, don't expect it to apply cleanly (it wouldn't anyway in
linux 2.6.14) and tell me if there is any problem with it.
Besides including a comment in
16 matches
Mail list logo
