On Mon, Jul 02, 2001 at 08:22:55PM -0400, David T Eger wrote:
>
> I have been working on a driver for a PowerPC PCI card/framebuffer device,
> and noticed that the standard readl() and writel() for this platform to
> byte swapping, since PowerPC runs big-endian. However, at least for my
>
On Mon, Jul 02, 2001 at 08:22:55PM -0400, David T Eger wrote:
I have been working on a driver for a PowerPC PCI card/framebuffer device,
and noticed that the standard readl() and writel() for this platform to
byte swapping, since PowerPC runs big-endian. However, at least for my
hardware
On Tue, Apr 17, 2001 at 09:39:15PM -0700, Dawson Engler wrote:
> Hi All,
>
> at the suggestion of Chris ([EMAIL PROTECTED]) I wrote a simple
> checker to warn when the length parameter to copy_*_user was (1) an
> integer and (2) not checked < 0.
>
> As an example, the ipv6 routine
On Tue, Apr 17, 2001 at 09:39:15PM -0700, Dawson Engler wrote:
Hi All,
at the suggestion of Chris ([EMAIL PROTECTED]) I wrote a simple
checker to warn when the length parameter to copy_*_user was (1) an
integer and (2) not checked 0.
As an example, the ipv6 routine
On Thu, Apr 12, 2001 at 09:04:28PM -0700, Andre Hedrick wrote:
> On Thu, 12 Apr 2001, george anzinger wrote:
>
> > Actually we could do the same thing they did for errno, i.e.
> >
> > #define jiffies get_jiffies()
> > extern unsigned get_jiffies(void);
>
> > No, not really. HZ still defines
On Thu, Apr 12, 2001 at 09:04:28PM -0700, Andre Hedrick wrote:
On Thu, 12 Apr 2001, george anzinger wrote:
Actually we could do the same thing they did for errno, i.e.
#define jiffies get_jiffies()
extern unsigned get_jiffies(void);
No, not really. HZ still defines the units of
On Tue, Apr 10, 2001 at 02:04:17PM +0200, Mikulas Patocka wrote:
>
> Adding and removing timers happens much more frequently than PIT tick, so
> comparing these times is pointless.
>
> If you have some device and timer protecting it from lockup on buggy
> hardware, you actually
>
> send
On Mon, Apr 09, 2001 at 11:35:44PM +0100, Alan Cox wrote:
> > > Its worth doing even on the ancient x86 boards with the PIT.
> >
> > Note that programming the PIT is slw and doing it on every timer
> > add_timer/del_timer would be a pain.
>
> You only have to do it occasionally.
>
>
On Mon, Apr 09, 2001 at 11:35:44PM +0100, Alan Cox wrote:
Its worth doing even on the ancient x86 boards with the PIT.
Note that programming the PIT is slw and doing it on every timer
add_timer/del_timer would be a pain.
You only have to do it occasionally.
When you add a
On Tue, Apr 10, 2001 at 02:04:17PM +0200, Mikulas Patocka wrote:
Adding and removing timers happens much more frequently than PIT tick, so
comparing these times is pointless.
If you have some device and timer protecting it from lockup on buggy
hardware, you actually
send request to
On Mon, Mar 05, 2001 at 07:17:18PM +, Padraig Brady wrote:
> Hmm.. useful until you actually want to modify a linked file,
> but then your modifying the file in all "merged" trees.
Use emacs, because you can configure it to do something
appropriate with linked files. But for those of us
On Mon, Mar 05, 2001 at 07:17:18PM +, Padraig Brady wrote:
Hmm.. useful until you actually want to modify a linked file,
but then your modifying the file in all "merged" trees.
Use emacs, because you can configure it to do something
appropriate with linked files. But for those of us
On Mon, Dec 18, 2000 at 10:51:09AM -0500, Dana Lacoste wrote:
>
> Can we get a #3 going? I think it could really help both the cross-compile
> people and those who just want to make sure their modules are compiling in
> the 'correct' environment. It also allows for things like 'kgcc vs. gcc'
On Mon, Dec 18, 2000 at 10:51:09AM -0500, Dana Lacoste wrote:
Can we get a #3 going? I think it could really help both the cross-compile
people and those who just want to make sure their modules are compiling in
the 'correct' environment. It also allows for things like 'kgcc vs. gcc' to
On Fri, Dec 01, 2000 at 09:26:29AM +, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > Not necessarily - it all depends on what your driver does. In many
> > cases, supporting 2.2 and 2.4 is easy, and all you need are a few
> > #if's. It's certainly much better to have a dozen or so
On Fri, Dec 01, 2000 at 09:26:29AM +, David Woodhouse wrote:
[EMAIL PROTECTED] said:
Not necessarily - it all depends on what your driver does. In many
cases, supporting 2.2 and 2.4 is easy, and all you need are a few
#if's. It's certainly much better to have a dozen or so #if's
On Tue, Nov 14, 2000 at 05:44:42PM -0600, Timur Tabi wrote:
> ** Reply to message from Keith Owens <[EMAIL PROTECTED]> on Wed, 15 Nov 2000
> 10:41:42 +1100
>
>
> > __NO_VERSION__ must be defined before #include .
>
> It is:
>
> #ifdef LINUX
> #ifndef __ENTRY_C__
> #define __NO_VERSION__
>
On Tue, Nov 14, 2000 at 09:59:22AM +0100, Olaf Kirch wrote:
> On Tue, Nov 14, 2000 at 12:06:32AM +0100, Michal Zalewski wrote:
> > Maybe I am missing something, but at least for me, modprobe
> > vulnerabilities are exploitable via privledged networking services,
> > nothing more.
>
> Maybe not.
On Tue, Nov 14, 2000 at 09:59:22AM +0100, Olaf Kirch wrote:
On Tue, Nov 14, 2000 at 12:06:32AM +0100, Michal Zalewski wrote:
Maybe I am missing something, but at least for me, modprobe
vulnerabilities are exploitable via privledged networking services,
nothing more.
Maybe not. ncpfs for
On Tue, Nov 14, 2000 at 05:44:42PM -0600, Timur Tabi wrote:
** Reply to message from Keith Owens [EMAIL PROTECTED] on Wed, 15 Nov 2000
10:41:42 +1100
__NO_VERSION__ must be defined before #include module.h.
It is:
#ifdef LINUX
#ifndef __ENTRY_C__
#define __NO_VERSION__
#endif
20 matches
Mail list logo
