On Sunday 29 July 2007 07:58, Adrian Bunk wrote:
> -DEVICE_ATTR(authorized_default, 0644,
> - usb_host_authorized_default_show,
> - usb_host_authorized_default_store);
> +static DEVICE_ATTR(authorized_default, 0644,
> > + usb_host_authorized_default_show,
Ack,
On Sunday 29 July 2007 07:58, Adrian Bunk wrote:
-DEVICE_ATTR(authorized_default, 0644,
- usb_host_authorized_default_show,
- usb_host_authorized_default_store);
+static DEVICE_ATTR(authorized_default, 0644,
+ usb_host_authorized_default_show,
Ack, patchset
On Tuesday 27 February 2007 12:45, Ingo Oeser wrote:
> Hi Inaky,
>
> On Tuesday, 27. February 2007, Inaky Perez-Gonzalez wrote:
> > On Monday 26 February 2007 18:18, Alan wrote:
> > > > Yeah, I need semaphore. This is a hw register that says when the hw
> > >
On Tuesday 27 February 2007 12:45, Ingo Oeser wrote:
Hi Inaky,
On Tuesday, 27. February 2007, Inaky Perez-Gonzalez wrote:
On Monday 26 February 2007 18:18, Alan wrote:
Yeah, I need semaphore. This is a hw register that says when the hw
is ready to accept a new command. Code that wants
On Monday 26 February 2007 18:18, Alan wrote:
> > Yeah, I need semaphore. This is a hw register that says when the hw
> > is ready to accept a new command. Code that wants to send commands has
> > to down the semaphore and then send it. When hw is ready to get a new
> > command, it sends and IRQ
On Monday 26 February 2007 16:33, Christoph Hellwig wrote:
> On Mon, Feb 26, 2007 at 04:13:38PM -0800, [EMAIL PROTECTED] wrote:
> > Introduce down_interruptible_timeout() using timers to make the waiter
> > stop waiting by simulating a signal (see first patch for more
> > details). As well
On Monday 26 February 2007 16:33, Christoph Hellwig wrote:
On Mon, Feb 26, 2007 at 04:13:38PM -0800, [EMAIL PROTECTED] wrote:
Introduce down_interruptible_timeout() using timers to make the waiter
stop waiting by simulating a signal (see first patch for more
details). As well introduce
On Monday 26 February 2007 18:18, Alan wrote:
Yeah, I need semaphore. This is a hw register that says when the hw
is ready to accept a new command. Code that wants to send commands has
to down the semaphore and then send it. When hw is ready to get a new
command, it sends and IRQ and the
null 2004-06-24 14:04:38.0 -0400
+++ 2.6.12-rc4-jak/include/linux/timeout.h 2005-05-18 13:53:14.212416002
-0400
@@ -0,0 +1,48 @@
+/*
+ * Extended timeout specification
+ *
+ * (C) 2002-2005 Intel Corp
+ * Inaky Perez-Gonzalez <[EMAIL PROTECTED]>.
+ *
+ * Licensed under the F
2004-06-24 14:04:38.0 -0400
+++ 2.6.12-rc4-jak/include/linux/timeout.h 2005-05-18 13:53:14.212416002
-0400
@@ -0,0 +1,48 @@
+/*
+ * Extended timeout specification
+ *
+ * (C) 2002-2005 Intel Corp
+ * Inaky Perez-Gonzalez [EMAIL PROTECTED].
+ *
+ * Licensed under the FSF's GNU Public
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>> this includes fixes from Daniel Walker, which could fix the plist
>> related slowdown bugs:
> there are still some problems remaining: i just ran Esben Nielsen's
> priority-inheritance validation testsuite, and the plist code gives
> a worst-case
Ingo Molnar [EMAIL PROTECTED] writes:
this includes fixes from Daniel Walker, which could fix the plist
related slowdown bugs:
there are still some problems remaining: i just ran Esben Nielsen's
priority-inheritance validation testsuite, and the plist code gives
a worst-case latency of 9.0
> Petr Baudis <[EMAIL PROTECTED]> writes:
> Remember that it's an URL (so you can't use '%'), and '#' is the
> canonical URL fragment identifier delimiter. (And fragments are
> perfect for this kind of thing, if you look at the RFC, BTW.)
Ouch, true--rule out %...
> Still, why would you
> Petr Baudis <[EMAIL PROTECTED]> writes:
> I've just added to git-pasky a possibility to refer to branches
> inside of repositories by a fragment identifier:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#testing
> will refer to your testing branch in that
Petr Baudis [EMAIL PROTECTED] writes:
I've just added to git-pasky a possibility to refer to branches
inside of repositories by a fragment identifier:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#testing
will refer to your testing branch in that repository.
Can we
Petr Baudis [EMAIL PROTECTED] writes:
Remember that it's an URL (so you can't use '%'), and '#' is the
canonical URL fragment identifier delimiter. (And fragments are
perfect for this kind of thing, if you look at the RFC, BTW.)
Ouch, true--rule out %...
Still, why would you escape it? My
>>>>> Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
>> >>>>> Steven Rostedt <[EMAIL PROTECTED]> writes:
>>
>> I see--would the following fit your view?
>>
> I
>>>>> Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
>> Back to my example before: in fusyn, a user space lock is a kernel
>> space lock with a wrapper, that provides all that is necessary for
>
>>>>> Steven Rostedt <[EMAIL PROTECTED]> writes:
>> On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
> I have to agree with Inaky too. Fundamentally, PI is the same for
> the system regardless of if the locks are user or kernel. I stil
> Bill Huey (hui) <[EMAIL PROTECTED]> writes:
> Ok, I've been thinking about these issues and I believe there are a
> number of misunderstandings here. The user and kernel space mutexes
> need to be completely different implementations. I'll have more on
> this later.
> First of all,
> gabriel <[EMAIL PROTECTED]> writes:
> Hi Im trying to boot an encrypted file system using an initrd on a
> USB. I use syslinux for the actual boot process as I couldnt get
> Grub to boot of it for some reason. This is the .cfg
> ...
> ...
> ...
> Kernel panic - not syncing: VFS: Unable
gabriel [EMAIL PROTECTED] writes:
Hi Im trying to boot an encrypted file system using an initrd on a
USB. I use syslinux for the actual boot process as I couldnt get
Grub to boot of it for some reason. This is the .cfg
...
...
...
Kernel panic - not syncing: VFS: Unable to mount root
Bill Huey (hui) [EMAIL PROTECTED] writes:
Ok, I've been thinking about these issues and I believe there are a
number of misunderstandings here. The user and kernel space mutexes
need to be completely different implementations. I'll have more on
this later.
First of all, priority
Steven Rostedt [EMAIL PROTECTED] writes:
On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
I have to agree with Inaky too. Fundamentally, PI is the same for
the system regardless of if the locks are user or kernel. I still
don't see the difference here. But for other reasons
Steven Rostedt [EMAIL PROTECTED] writes:
On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
Back to my example before: in fusyn, a user space lock is a kernel
space lock with a wrapper, that provides all that is necessary for
doing the fast path and handling user-space specific
Steven Rostedt [EMAIL PROTECTED] writes:
On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
Steven Rostedt [EMAIL PROTECTED] writes:
I see--would the following fit your view?
I think it's time that I take a look at the fusyn code. I don't have
all the emails on this thread
26 matches
Mail list logo
