On Wed, 2 Feb 2005 21:50:49 -0500, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> Please consider the benefits to GPL software ;-)
Given his @gnu.org posts, I'd suggest he's between a rock and a hard
place and can't just do that. Companies don't always understand these
arguments :-)
On the techical
On Wed, 2 Feb 2005 21:50:49 -0500, Kyle Moffett [EMAIL PROTECTED] wrote:
Please consider the benefits to GPL software ;-)
Given his @gnu.org posts, I'd suggest he's between a rock and a hard
place and can't just do that. Companies don't always understand these
arguments :-)
On the techical
On Sun, 30 Jan 2005 14:06:17 -0800 (PST), Eugene K <[EMAIL PROTECTED]> wrote:
> Where could I find a documented interface between a
> Board Support Package layer and Linux Kernel itself ?
There is no Board Support Package layer of which you speak. Linux
doesn't have a hal (well it does, but it's
On Sun, 30 Jan 2005 14:06:17 -0800 (PST), Eugene K [EMAIL PROTECTED] wrote:
Where could I find a documented interface between a
Board Support Package layer and Linux Kernel itself ?
There is no Board Support Package layer of which you speak. Linux
doesn't have a hal (well it does, but it's a
[excuse formatting, adhoc connectivity]
Ben writes:
> And ppc64 adds a flattened device-tree format, even better imho :)
This is exactly what I was looking at - pulling that in to ppc32, helps
with stuff like kexec too. Like everything else, it helps to have people
moaning at me to make me
Kumar Gala wrote:
We did talk about looking at using some work Ben did in ppc64 with OF in
ppc32. John Masters was looking into this, but I havent heard much from
him on it lately.
I went rather quiet since I had nothing new to add to the discussion.
But I did plan to get somewhere before
Kumar Gala wrote:
We did talk about looking at using some work Ben did in ppc64 with OF in
ppc32. John Masters was looking into this, but I havent heard much from
him on it lately.
I went rather quiet since I had nothing new to add to the discussion.
But I did plan to get somewhere before
[excuse formatting, adhoc connectivity]
Ben writes:
And ppc64 adds a flattened device-tree format, even better imho :)
This is exactly what I was looking at - pulling that in to ppc32, helps
with stuff like kexec too. Like everything else, it helps to have people
moaning at me to make me
Jeremy Jackson wrote:
> try bridging instead if ip forwarding. use netfilter too if you want
I mentioned bridging before - I don't want some kind of transparent
bridge, really so what I would need is for the router to be contactable
in the same way as before and for regular traffic to pass
Hello,
I have a brain-dead application here which relies on broadcast
traffic for client/server discovery and I have a question with regard
to forwarding broadcast traffic.
A small part of my local LAN looks like this:
REST OF LAN
|
Hello,
I have a brain-dead application here which relies on broadcast
traffic for client/server discovery and I have a question with regard
to forwarding broadcast traffic.
A small part of my local LAN looks like this:
REST OF LAN
|
Jeremy Jackson wrote:
try bridging instead if ip forwarding. use netfilter too if you want
I mentioned bridging before - I don't want some kind of transparent
bridge, really so what I would need is for the router to be contactable
in the same way as before and for regular traffic to pass
Marc Mutz wrote:
> A 2.4.0.1 should be on ftp.kernel.org/pub/linux/kernel/crypto/v2.4/.
> But it has been heavily re-worked. I haven't got my hands on that one
> and will keep quiet as to what extend that patch is produiction-ready,
> but I remember that the loop driver in 2.4.0 still can stall
Marc Mutz wrote:
A 2.4.0.1 should be on ftp.kernel.org/pub/linux/kernel/crypto/v2.4/.
But it has been heavily re-worked. I haven't got my hands on that one
and will keep quiet as to what extend that patch is produiction-ready,
but I remember that the loop driver in 2.4.0 still can stall your
Hello,
I am aware of work being done to create crypto patches for 2.4 however I
am wondering what kind of time scale is likely to be involved before a
patch for 2.4.0 becomes available and, more importantly, when such a
patch will be suitable for daily use (disclaimers withstanding
obviously).
Hello,
I am aware of work being done to create crypto patches for 2.4 however I
am wondering what kind of time scale is likely to be involved before a
patch for 2.4.0 becomes available and, more importantly, when such a
patch will be suitable for daily use (disclaimers withstanding
obviously).
801 - 816 of 816 matches
Mail list logo
