On 2015-04-14 15:43, Greg Kroah-Hartman wrote:
On Tue, Apr 14, 2015 at 08:35:33PM +0100, Al Viro wrote:
On Tue, Apr 14, 2015 at 09:23:57PM +0200, Greg Kroah-Hartman wrote:
I agree. You've sent a pull request for an unfortunate design. I
don't think that unfortunate design belongs in the
On 2015-04-14 15:43, Greg Kroah-Hartman wrote:
On Tue, Apr 14, 2015 at 08:35:33PM +0100, Al Viro wrote:
On Tue, Apr 14, 2015 at 09:23:57PM +0200, Greg Kroah-Hartman wrote:
I agree. You've sent a pull request for an unfortunate design. I
don't think that unfortunate design belongs in the
On 2015-04-08 09:19, Pengfei Yuan wrote:
2015-04-08 20:06 GMT+08:00 Austin S Hemmelgarn :
I can't remember any off the top of my head, but it does say explicitly in
the GCC manual to be careful with -O3. IIRC, most of the issues relate to
-O3 enabling -ffast-math (which tends to really mess
On 2015-04-08 08:19, Richard Weinberger wrote:
On Wed, Apr 8, 2015 at 3:00 AM, Pengfei Yuan <0xcool...@gmail.com> wrote:
Could you please provide some examples that I can investigate?
Thanks!
It would be awesome if you could find out which gcc optimizations
cause the speed up.
"gcc -c -Q -O3
On 2015-04-07 21:00, Pengfei Yuan wrote:
Could you please provide some examples that I can investigate?
Thanks!
2015-04-08 2:05 GMT+08:00 Austin S Hemmelgarn :
On 2015-04-07 06:09, Mike Galbraith wrote:
On Tue, 2015-04-07 at 15:56 +0800, Pengfei Yuan wrote:
I am trying legacy GCC versions
On 2015-04-07 21:00, Pengfei Yuan wrote:
Could you please provide some examples that I can investigate?
Thanks!
2015-04-08 2:05 GMT+08:00 Austin S Hemmelgarn ahferro...@gmail.com:
On 2015-04-07 06:09, Mike Galbraith wrote:
On Tue, 2015-04-07 at 15:56 +0800, Pengfei Yuan wrote:
I am trying
On 2015-04-08 09:19, Pengfei Yuan wrote:
2015-04-08 20:06 GMT+08:00 Austin S Hemmelgarn ahferro...@gmail.com:
I can't remember any off the top of my head, but it does say explicitly in
the GCC manual to be careful with -O3. IIRC, most of the issues relate to
-O3 enabling -ffast-math (which
On 2015-04-08 08:19, Richard Weinberger wrote:
On Wed, Apr 8, 2015 at 3:00 AM, Pengfei Yuan 0xcool...@gmail.com wrote:
Could you please provide some examples that I can investigate?
Thanks!
It would be awesome if you could find out which gcc optimizations
cause the speed up.
gcc -c -Q -O3
On 2015-04-07 06:09, Mike Galbraith wrote:
> On Tue, 2015-04-07 at 15:56 +0800, Pengfei Yuan wrote:
>> I am trying legacy GCC versions.
>> But I am not able to try different architectures.
>
> The point of my reply wasn't to get you to actually test the world ;-)
>
> I was indirectly pointing
On 2015-04-07 06:09, Mike Galbraith wrote:
On Tue, 2015-04-07 at 15:56 +0800, Pengfei Yuan wrote:
I am trying legacy GCC versions.
But I am not able to try different architectures.
The point of my reply wasn't to get you to actually test the world ;-)
I was indirectly pointing out that
On 2015-03-11 22:28, Aleksa Sarai wrote:
I did not necessarily word this very clearly. What I meant is that
/proc/sys/kernel/pid_max is essentially an external limiting factor that
caps the total number of pids that can be under the root cgroup and it's
children, not that the cgroup in any way
On 2015-03-11 22:28, Aleksa Sarai wrote:
I did not necessarily word this very clearly. What I meant is that
/proc/sys/kernel/pid_max is essentially an external limiting factor that
caps the total number of pids that can be under the root cgroup and it's
children, not that the cgroup in any way
On 2015-03-10 08:31, Aleksa Sarai wrote:
Hi Austin,
Does pids limit make sense in the root cgroup?
I would say it kind of does, although I would just expect it to track
/proc/sys/kernel/pid_max (either as a read-only value, or as an
alternative way to set it).
Personally, that seems
On 2015-03-10 08:31, Aleksa Sarai wrote:
Hi Austin,
Does pids limit make sense in the root cgroup?
I would say it kind of does, although I would just expect it to track
/proc/sys/kernel/pid_max (either as a read-only value, or as an
alternative way to set it).
Personally, that seems
On 2015-03-10 04:10, Aleksa Sarai wrote:
Hi Austin,
Does pids limit make sense in the root cgroup?
I would say it kind of does, although I would just expect it to track
/proc/sys/kernel/pid_max (either as a read-only value, or as an alternative
way to set it).
Personally, that seems
On 2015-03-10 04:10, Aleksa Sarai wrote:
Hi Austin,
Does pids limit make sense in the root cgroup?
I would say it kind of does, although I would just expect it to track
/proc/sys/kernel/pid_max (either as a read-only value, or as an alternative
way to set it).
Personally, that seems
On 2015-03-08 23:34, Tejun Heo wrote:
Does pids limit make sense in the root cgroup?
I would say it kind of does, although I would just expect it to track
/proc/sys/kernel/pid_max (either as a read-only value, or as an
alternative way to set it).
--
To unsubscribe from this list: send the
On 2015-03-08 23:34, Tejun Heo wrote:
Does pids limit make sense in the root cgroup?
I would say it kind of does, although I would just expect it to track
/proc/sys/kernel/pid_max (either as a read-only value, or as an
alternative way to set it).
--
To unsubscribe from this list: send the
On 2015-03-04 09:09, Juergen Gross wrote:
The main question whether it is worth to consider this alternative is
the performance aspect. Does anyone have an idea which USB devices would
typically be used via pvusb? I'd suspect memory sticks and USB disks
and perhaps webcams being the most
On 2015-03-04 09:09, Juergen Gross wrote:
The main question whether it is worth to consider this alternative is
the performance aspect. Does anyone have an idea which USB devices would
typically be used via pvusb? I'd suspect memory sticks and USB disks
and perhaps webcams being the most
On 2015-02-28 11:43, Tejun Heo wrote:
Hello, Tim.
On Sat, Feb 28, 2015 at 08:38:07AM -0800, Tim Hockin wrote:
I know there is not much concern for legacy-system problems, but it is
worth adding this case - there are systems that limit PIDs for other
reasons, eg broken infrastructure that
On 2015-02-28 11:43, Tejun Heo wrote:
Hello, Tim.
On Sat, Feb 28, 2015 at 08:38:07AM -0800, Tim Hockin wrote:
I know there is not much concern for legacy-system problems, but it is
worth adding this case - there are systems that limit PIDs for other
reasons, eg broken infrastructure that
On 2015-02-27 12:06, Tejun Heo wrote:
Hello,
On Fri, Feb 27, 2015 at 11:42:10AM -0500, Austin S Hemmelgarn wrote:
Kernel memory consumption isn't the only valid reason to want to limit the
number of processes in a cgroup. Limiting the number of processes is very
useful to ensure
On 2015-02-27 06:49, Tejun Heo wrote:
Hello,
On Mon, Feb 23, 2015 at 02:08:09PM +1100, Aleksa Sarai wrote:
The current state of resource limitation for the number of open
processes (as well as the number of open file descriptors) requires you
to use setrlimit(2), which means that you are
On 2015-02-27 06:49, Tejun Heo wrote:
Hello,
On Mon, Feb 23, 2015 at 02:08:09PM +1100, Aleksa Sarai wrote:
The current state of resource limitation for the number of open
processes (as well as the number of open file descriptors) requires you
to use setrlimit(2), which means that you are
On 2015-02-27 12:06, Tejun Heo wrote:
Hello,
On Fri, Feb 27, 2015 at 11:42:10AM -0500, Austin S Hemmelgarn wrote:
Kernel memory consumption isn't the only valid reason to want to limit the
number of processes in a cgroup. Limiting the number of processes is very
useful to ensure
On 2015-02-04 09:19, Alexander Holler wrote:
Am 04.02.2015 um 14:29 schrieb Alexander Holler:
I'm really sorry that I can't spend several unpaid months with reading
and understanding ever changing linux kernel sources in order to become
a Linux filesystem expert and send some fully working
On 2015-02-04 09:19, Alexander Holler wrote:
Am 04.02.2015 um 14:29 schrieb Alexander Holler:
I'm really sorry that I can't spend several unpaid months with reading
and understanding ever changing linux kernel sources in order to become
a Linux filesystem expert and send some fully working
On 2015-02-03 07:31, Takashi Iwai wrote:
Then,
udev unlocks the media and issues the SCSI eject ioctl unconditionally
when DISK_EVENT_EJECT_REQUEST event is received. Since SCSI ioctl
doesn't take the open refcount into account, it results in the
forcible eject.
Which again is the expected
On 2015-02-03 07:31, Takashi Iwai wrote:
Then,
udev unlocks the media and issues the SCSI eject ioctl unconditionally
when DISK_EVENT_EJECT_REQUEST event is received. Since SCSI ioctl
doesn't take the open refcount into account, it results in the
forcible eject.
Which again is the expected
On 2015-02-02 14:34, Maciej W. Rozycki wrote:
On Mon, 2 Feb 2015, Kay Sievers wrote:
I thought that fixing the udev behavior would solve the problem. But
it turned out that I was too naive. A bigger problem is that all
user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
see
On 2015-02-02 13:47, Mimi Zohar wrote:
On Mon, 2015-02-02 at 18:08 +, Serge Hallyn wrote:
Quoting Casey Schaufler (ca...@schaufler-ca.com):
I'm game to participate in such an effort. The POSIX scheme
is workable, but given that it's 20 years old and hasn't
developed real traction it's hard
On 2015-01-30 20:58, Calvin Owens wrote:
On Thursday 01/29 at 17:30 -0800, Kees Cook wrote:
On Tue, Jan 27, 2015 at 8:38 PM, Calvin Owens wrote:
On Monday 01/26 at 15:43 -0800, Andrew Morton wrote:
On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov wrote:
On Mon, Jan 26, 2015 at
On 2015-02-02 14:34, Maciej W. Rozycki wrote:
On Mon, 2 Feb 2015, Kay Sievers wrote:
I thought that fixing the udev behavior would solve the problem. But
it turned out that I was too naive. A bigger problem is that all
user-space stuff misinterprets DISK_EVENT_EJECT_REQUEST event: they
see
On 2015-01-30 20:58, Calvin Owens wrote:
On Thursday 01/29 at 17:30 -0800, Kees Cook wrote:
On Tue, Jan 27, 2015 at 8:38 PM, Calvin Owens calvinow...@fb.com wrote:
On Monday 01/26 at 15:43 -0800, Andrew Morton wrote:
On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote:
On 2015-02-02 13:47, Mimi Zohar wrote:
On Mon, 2015-02-02 at 18:08 +, Serge Hallyn wrote:
Quoting Casey Schaufler (ca...@schaufler-ca.com):
I'm game to participate in such an effort. The POSIX scheme
is workable, but given that it's 20 years old and hasn't
developed real traction it's hard
On 2015-01-30 14:48, Casey Schaufler wrote:
On 1/30/2015 11:13 AM, j...@joshtriplett.org wrote:
On Thu, Jan 29, 2015 at 06:25:23PM -0800, Casey Schaufler wrote:
On 1/29/2015 5:36 PM, Paul E. McKenney wrote:
A few K here, a few K there, and pretty soon you actually fit into the
small-memory
On 2015-01-30 14:48, Casey Schaufler wrote:
On 1/30/2015 11:13 AM, j...@joshtriplett.org wrote:
On Thu, Jan 29, 2015 at 06:25:23PM -0800, Casey Schaufler wrote:
On 1/29/2015 5:36 PM, Paul E. McKenney wrote:
A few K here, a few K there, and pretty soon you actually fit into the
small-memory
On 2015-01-22 08:46, David Herrmann wrote:
Hi Michael
On Thu, Jan 22, 2015 at 11:18 AM, Michael Kerrisk (man-pages)
wrote:
* API oddities such as the 'kernel_flags' fields. Why do I need to
be told what flags the kernel supports on *every* operation?
If we only returned EINVAL on invalid
On 2015-01-22 08:46, David Herrmann wrote:
Hi Michael
On Thu, Jan 22, 2015 at 11:18 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
* API oddities such as the 'kernel_flags' fields. Why do I need to
be told what flags the kernel supports on *every* operation?
If we only
On 2015-01-14 18:01, Andrea Arcangeli wrote:
7) distributed shared memory that could allow simultaneous mapping of
regions marked readonly and collapse them on the first exclusive
write. I'm mentioning it as a corollary, because I'm not aware of
anybody who is planning to use it that
On 2015-01-14 18:01, Andrea Arcangeli wrote:
7) distributed shared memory that could allow simultaneous mapping of
regions marked readonly and collapse them on the first exclusive
write. I'm mentioning it as a corollary, because I'm not aware of
anybody who is planning to use it that
On 2014-11-21 22:58, Andrey Utkin wrote:
(I was asked to research this topic to help students. So please ignore
this topic if all you want to say is that it is OK to code in editor
without autocompletion and any other integration, and that there's LXR
website. We all know that.)
Dear kernel
On 2014-11-21 22:58, Andrey Utkin wrote:
(I was asked to research this topic to help students. So please ignore
this topic if all you want to say is that it is OK to code in editor
without autocompletion and any other integration, and that there's LXR
website. We all know that.)
Dear kernel
On 2014-11-11 06:38, One Thousand Gnomes wrote:
look further into the options I have set in my kernel build, I may have
changed something else without remembering between booting with and
without the CSM enabled.
It could also be that the non-CSM BIOS somehow remaps the CMOS registers.
I
On 2014-11-11 06:38, One Thousand Gnomes wrote:
look further into the options I have set in my kernel build, I may have
changed something else without remembering between booting with and
without the CSM enabled.
It could also be that the non-CSM BIOS somehow remaps the CMOS registers.
I
On 2014-11-10 12:04, Matthew Garrett wrote:
On Mon, Nov 10, 2014 at 11:45:06AM -0500, Austin S Hemmelgarn wrote:
I agree, without it you need PC CMOS RTC support to access the RTC
on most systems, which in turn means that you have to enable the CSM
in the EFI firmware, which is annoying cause
On 2014-11-10 11:23, Pali Rohár wrote:
On Monday 10 November 2014 12:22:13 Matt Fleming wrote:
On Sun, 2014-11-09 at 19:22 +0100, Borislav Petkov wrote:
On Sun, Nov 09, 2014 at 06:37:46PM +0100, Pali Rohár wrote:
this patch totally disabled efi rfc driver on x86 machines
at compile time. But
On 2014-11-10 09:22, One Thousand Gnomes wrote:
wouldn't be accepted. (BTW, if you're going to do this, note that ^T
could be remapped to any control character via stty; so to do this we
would need to define an extra index in c_cc[] array in the struct
termios.)
We have 19 entries in the
On 2014-11-10 09:22, One Thousand Gnomes wrote:
wouldn't be accepted. (BTW, if you're going to do this, note that ^T
could be remapped to any control character via stty; so to do this we
would need to define an extra index in c_cc[] array in the struct
termios.)
We have 19 entries in the
On 2014-11-10 11:23, Pali Rohár wrote:
On Monday 10 November 2014 12:22:13 Matt Fleming wrote:
On Sun, 2014-11-09 at 19:22 +0100, Borislav Petkov wrote:
On Sun, Nov 09, 2014 at 06:37:46PM +0100, Pali Rohár wrote:
this patch totally disabled efi rfc driver on x86 machines
at compile time. But
On 2014-11-10 12:04, Matthew Garrett wrote:
On Mon, Nov 10, 2014 at 11:45:06AM -0500, Austin S Hemmelgarn wrote:
I agree, without it you need PC CMOS RTC support to access the RTC
on most systems, which in turn means that you have to enable the CSM
in the EFI firmware, which is annoying cause
On 2014-11-05 15:14, Theodore Ts'o wrote:
On Wed, Nov 05, 2014 at 02:31:12PM -0500, Austin S Hemmelgarn wrote:
SIGINFO prints the status of the process to the terminal; BSD cp, for example,
shows show much data it's copied:
$ cp large_file /dev/null
load: 1.39 cmd: cp 85837
On 2014-11-05 10:17, Martin Tournoij wrote:
Hi there,
As a long-time BSD user, I have become quite used to the SIGINFO (sent with ^t)
feature; after switching to Linux as my desktop a few months ago, I very much
miss this.
SIGINFO prints the status of the process to the terminal; BSD cp, for
On 2014-11-05 10:17, Martin Tournoij wrote:
Hi there,
As a long-time BSD user, I have become quite used to the SIGINFO (sent with ^t)
feature; after switching to Linux as my desktop a few months ago, I very much
miss this.
SIGINFO prints the status of the process to the terminal; BSD cp, for
On 2014-11-05 15:14, Theodore Ts'o wrote:
On Wed, Nov 05, 2014 at 02:31:12PM -0500, Austin S Hemmelgarn wrote:
SIGINFO prints the status of the process to the terminal; BSD cp, for example,
shows show much data it's copied:
$ cp large_file /dev/null
press ^t
load: 1.39 cmd: cp
On 2014-10-17 11:53, Sandy Harris wrote:
I've been reading the debates around systemd, haven't reached any firm
conclusion but the criticism that Unix programs should "do one thing
and do it well" certainly resonates with me.
On the other hand, this may be one of those cases where theory and
On 2014-10-17 11:53, Sandy Harris wrote:
I've been reading the debates around systemd, haven't reached any firm
conclusion but the criticism that Unix programs should do one thing
and do it well certainly resonates with me.
On the other hand, this may be one of those cases where theory and
On 2014-10-07 15:28, Grozdan wrote:
Hi,
Basically, my problem is this:
I'm doing a lot of audio/video encoding on an AMD FX8350. The encoder
process always runs at nice 10. Even so, my whole system feels very
sluggish. Switching between different app windows and/or virtual
desktops takes up
On 2014-10-07 15:28, Grozdan wrote:
Hi,
Basically, my problem is this:
I'm doing a lot of audio/video encoding on an AMD FX8350. The encoder
process always runs at nice 10. Even so, my whole system feels very
sluggish. Switching between different app windows and/or virtual
desktops takes up
On 2014-09-11 11:41, Vladimir Davydov wrote:
> Though hard memory limits suit perfectly for sand-boxing, they are not
> that efficient when it comes to partitioning a server's resources among
> multiple containers. The point is a container consuming a particular
> amount of memory most of time may
On 2014-09-11 11:41, Vladimir Davydov wrote:
Though hard memory limits suit perfectly for sand-boxing, they are not
that efficient when it comes to partitioning a server's resources among
multiple containers. The point is a container consuming a particular
amount of memory most of time may
On 2014-09-04 13:29, Alexander Holler wrote:
> Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn:
>> On 2014-09-04 06:16, Alexander Holler wrote:
>>>
>>> It's a myth that C++ ends up in bigger code than C. At least in my
>>> experience. Especially when the l
On 2014-09-04 06:16, Alexander Holler wrote:
>
> It's a myth that C++ ends up in bigger code than C. At least in my
> experience. Especially when the latest additions to C++ are in effect
> (like the move-semantics in C++11 I like quiet a lot and which you get
> almost for free (by changing
On 2014-09-03 19:46, Andi Kleen wrote:
> "H. Peter Anvin" writes:
>
>> In a meeting earlier today, we discussed MSR access and that it could be
>> used to do bad things. The same applies to other forms of raw I/O
>> (/dev/mem, /dev/port, ioperm, iopl, etc.)
>
> I don't think it makes sense to
On 2014-09-03 19:46, Andi Kleen wrote:
H. Peter Anvin h.peter.an...@intel.com writes:
In a meeting earlier today, we discussed MSR access and that it could be
used to do bad things. The same applies to other forms of raw I/O
(/dev/mem, /dev/port, ioperm, iopl, etc.)
I don't think it
On 2014-09-04 06:16, Alexander Holler wrote:
It's a myth that C++ ends up in bigger code than C. At least in my
experience. Especially when the latest additions to C++ are in effect
(like the move-semantics in C++11 I like quiet a lot and which you get
almost for free (by changing nothing)
On 2014-09-04 13:29, Alexander Holler wrote:
Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn:
On 2014-09-04 06:16, Alexander Holler wrote:
It's a myth that C++ ends up in bigger code than C. At least in my
experience. Especially when the latest additions to C++ are in effect
(like the move
On 2014-08-26 18:00, Rob Landley wrote:
> On Tue, Aug 26, 2014 at 7:34 AM, Austin S Hemmelgarn
> wrote:
>> A lot of LiveCD's make use of this
>> to control hardware detection and module loading. The only open file
>> descriptors (i believe, I may be wrong) are 0
On 2014-08-26 18:00, Rob Landley wrote:
On Tue, Aug 26, 2014 at 7:34 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
A lot of LiveCD's make use of this
to control hardware detection and module loading. The only open file
descriptors (i believe, I may be wrong) are 0, 1, and 2, all
On 2014-08-26 01:48, Shea Levy wrote:
> Hi all,
>
> Is there any official documentation of the init process? I'm
> specifically interested in the process state at kernel handoff (argv,
> envp, open fds, etc.) as well as any special properties pid 1 has
> (parent of all orphans, anything else?).
>
On 2014-08-26 01:48, Shea Levy wrote:
Hi all,
Is there any official documentation of the init process? I'm
specifically interested in the process state at kernel handoff (argv,
envp, open fds, etc.) as well as any special properties pid 1 has
(parent of all orphans, anything else?).
On 2014-08-25 09:24, Pali Rohár wrote:
> Hi,
>
> On Monday 25 August 2014 14:45:13 Austin S Hemmelgarn wrote:
>> On 2014-08-24 08:46, Pali Rohár wrote:
>>> Hi,
>>>
>>> I would like to know what is state of linux UDF driver. It
>>> is experimenta
On 2014-08-24 08:46, Pali Rohár wrote:
> Hi,
>
> I would like to know what is state of linux UDF driver. It is
> experimental or is now suitable for storing data?
>
I know that read support works for every version I have tested, but I've
only tested it reading data from DVD's and Blu-Ray discs,
On 2014-08-24 08:46, Pali Rohár wrote:
Hi,
I would like to know what is state of linux UDF driver. It is
experimental or is now suitable for storing data?
I know that read support works for every version I have tested, but I've
only tested it reading data from DVD's and Blu-Ray discs, so I
On 2014-08-25 09:24, Pali Rohár wrote:
Hi,
On Monday 25 August 2014 14:45:13 Austin S Hemmelgarn wrote:
On 2014-08-24 08:46, Pali Rohár wrote:
Hi,
I would like to know what is state of linux UDF driver. It
is experimental or is now suitable for storing data?
I know that read support
On 2014-08-05 07:40, martin f krafft wrote:
> Hello,
>
> A NAS seems to be having RAM problems, leading me to want to swap
> out DIMMs until I found the offender; I'd rather not go to the rack
> every time I need to make a change.
>
> Is there a way to declare a DIMM unavailable to Linux with a
On 2014-08-05 07:40, martin f krafft wrote:
Hello,
A NAS seems to be having RAM problems, leading me to want to swap
out DIMMs until I found the offender; I'd rather not go to the rack
every time I need to make a change.
Is there a way to declare a DIMM unavailable to Linux with a boot
On 2014-08-04 10:21, Alan Stern wrote:
> On Mon, 4 Aug 2014, Austin S Hemmelgarn wrote:
>
>> On 2014-08-02 09:48, Alan Stern wrote:
>>> On Sat, 2 Aug 2014, Nick Krause wrote:
>>>
>>>> Hey Sharp,
>>>> After reading around seems people want sup
On 2014-08-02 09:48, Alan Stern wrote:
> On Sat, 2 Aug 2014, Nick Krause wrote:
>
>> Hey Sharp,
>> After reading around seems people want support for usb debugging in
>> kgdb or other usb based solutions.
>> If you and the other developers are able to help me out a bit as I am
>> new I can
On 2014-08-02 09:48, Alan Stern wrote:
On Sat, 2 Aug 2014, Nick Krause wrote:
Hey Sharp,
After reading around seems people want support for usb debugging in
kgdb or other usb based solutions.
If you and the other developers are able to help me out a bit as I am
new I can definitively write
On 2014-08-04 10:21, Alan Stern wrote:
On Mon, 4 Aug 2014, Austin S Hemmelgarn wrote:
On 2014-08-02 09:48, Alan Stern wrote:
On Sat, 2 Aug 2014, Nick Krause wrote:
Hey Sharp,
After reading around seems people want support for usb debugging in
kgdb or other usb based solutions.
If you
On 07/30/2014 12:54 AM, Nick Krause wrote:
> On Wed, Jul 30, 2014 at 12:37 AM, Gareth Pye wrote:
>> You've been replied to politely, now listen and do or shut up.
>>
>>
>> On Wed, Jul 30, 2014 at 1:54 PM, Nick Krause wrote:
>>>
>>> Hey Guys ,
>>> I am new to reading and writing kernel code.I
On 07/30/2014 12:54 AM, Nick Krause wrote:
On Wed, Jul 30, 2014 at 12:37 AM, Gareth Pye gar...@cerberos.id.au wrote:
You've been replied to politely, now listen and do or shut up.
On Wed, Jul 30, 2014 at 1:54 PM, Nick Krause xerofo...@gmail.com wrote:
Hey Guys ,
I am new to reading and
On 2014-07-29 13:08, Nick Krause wrote:
> On Mon, Jul 28, 2014 at 2:36 PM, Nick Krause wrote:
>> On Mon, Jul 28, 2014 at 12:19 PM, Austin S Hemmelgarn
>> wrote:
>>> On 2014-07-28 11:57, Nick Krause wrote:
>>>> On Mon, Jul 28, 2014 at 11:13 AM, Nick Krause
&g
On 2014-07-29 13:08, Nick Krause wrote:
On Mon, Jul 28, 2014 at 2:36 PM, Nick Krause xerofo...@gmail.com wrote:
On Mon, Jul 28, 2014 at 12:19 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 2014-07-28 11:57, Nick Krause wrote:
On Mon, Jul 28, 2014 at 11:13 AM, Nick Krause xerofo
On 2014-07-28 11:57, Nick Krause wrote:
> On Mon, Jul 28, 2014 at 11:13 AM, Nick Krause
> wrote:
>> On Mon, Jul 28, 2014 at 6:10 AM, Austin S Hemmelgarn
>> wrote:
>>> On 07/27/2014 11:21 PM, Nick Krause wrote:
>>>> On Sun, Jul 27, 2014 at 10:56 PM, Austin
On 07/27/2014 11:21 PM, Nick Krause wrote:
> On Sun, Jul 27, 2014 at 10:56 PM, Austin S Hemmelgarn
> wrote:
>> On 07/27/2014 04:47 PM, Nick Krause wrote:
>>> This may be a bad idea , but compression in brtfs seems to be only
>>> using one core to compress.
On 07/27/2014 11:21 PM, Nick Krause wrote:
On Sun, Jul 27, 2014 at 10:56 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 07/27/2014 04:47 PM, Nick Krause wrote:
This may be a bad idea , but compression in brtfs seems to be only
using one core to compress.
Depending on the CPU used
On 2014-07-28 11:57, Nick Krause wrote:
On Mon, Jul 28, 2014 at 11:13 AM, Nick Krause xerofo...@gmail.com
wrote:
On Mon, Jul 28, 2014 at 6:10 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 07/27/2014 11:21 PM, Nick Krause wrote:
On Sun, Jul 27, 2014 at 10:56 PM, Austin S Hemmelgarn
On 07/27/2014 04:47 PM, Nick Krause wrote:
> This may be a bad idea , but compression in brtfs seems to be only
> using one core to compress.
> Depending on the CPU used and the amount of cores in the CPU we can
> make this much faster
> with multiple cores. This seems bad by my reading at least I
On 07/27/2014 04:47 PM, Nick Krause wrote:
This may be a bad idea , but compression in brtfs seems to be only
using one core to compress.
Depending on the CPU used and the amount of cores in the CPU we can
make this much faster
with multiple cores. This seems bad by my reading at least I
On 2014-04-15 09:42, Emmanuel Colbus wrote:
> Now, back to the filesystem...
>
> In order to associate devices to their files, the Linux kernel uses
> their major and minor numbers. However, mine doesn't; instead, I've
> attributed myself a single group of values (major=0, minor=0, for both
>
On 2014-04-15 09:42, Emmanuel Colbus wrote:
Now, back to the filesystem...
In order to associate devices to their files, the Linux kernel uses
their major and minor numbers. However, mine doesn't; instead, I've
attributed myself a single group of values (major=0, minor=0, for both
On 2014-03-16 18:56, H. Peter Anvin wrote:
> On 03/03/2014 03:51 PM, Kees Cook wrote:
>> When bringing a new RNG source online, it seems like it would make sense
>> to use some of its bytes to make the system entropy pool more random,
>> as done with all sorts of other devices that contain
On 2014-03-16 18:56, H. Peter Anvin wrote:
On 03/03/2014 03:51 PM, Kees Cook wrote:
When bringing a new RNG source online, it seems like it would make sense
to use some of its bytes to make the system entropy pool more random,
as done with all sorts of other devices that contain per-device or
On 2014-03-07 07:42, Richard Weinberger wrote:
>
>
> Am 07.03.2014 13:39, schrieb Austin S Hemmelgarn:
>> On 2014-03-06 08:28, Richard Weinberger wrote:
>>> On Wed, Mar 5, 2014 at 6:37 AM, Jon Ringle
>>> wrote:
>>>>
>>>>
>>>&g
On 2014-03-06 08:28, Richard Weinberger wrote:
> On Wed, Mar 5, 2014 at 6:37 AM, Jon Ringle
> wrote:
>>
>>
>> On Wed, 5 Mar 2014, Greg KH wrote:
>>
>>> On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote:
+config CC_OPTIMIZE_FOR_SPEED +bool "Optimze for speed
(-O3)" +
On 2014-03-06 08:28, Richard Weinberger wrote:
On Wed, Mar 5, 2014 at 6:37 AM, Jon Ringle jrin...@gridpoint.com
wrote:
On Wed, 5 Mar 2014, Greg KH wrote:
On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote:
+config CC_OPTIMIZE_FOR_SPEED +bool Optimze for speed
(-O3) +
On 2014-03-07 07:42, Richard Weinberger wrote:
Am 07.03.2014 13:39, schrieb Austin S Hemmelgarn:
On 2014-03-06 08:28, Richard Weinberger wrote:
On Wed, Mar 5, 2014 at 6:37 AM, Jon Ringle jrin...@gridpoint.com
wrote:
On Wed, 5 Mar 2014, Greg KH wrote:
On Tue, Mar 04, 2014 at 07:01:49PM
501 - 600 of 650 matches
Mail list logo
