On 5/28/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
No, LZO as a visible option makes no practical sense. Why would
anyone want to build LZO into a kernel when there are no in-kernel
users of the code?
Agreed. It should be a auto-selected hidden config option.
-
To unsubscribe from this
On 28 May 2007, at 13:09, Nitin Gupta wrote:
This means:
1) Options in lib/Kconfig hidden (selectable by drivers as required)
LZO as hidden option has no practical sense. Although LZO should be
auto-selected when some dependent project is selected (e.g. reieser4)
- there should be separate
On 5/28/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
On 28 May 2007, at 07:59, Nitin Gupta wrote:
> If we get no perf. problems with this patch, then I beleive it is now
> suitable to inclusion in mainline. Further cleanups and optimizations
> can surely be done after that. It's still just
On 28 May 2007, at 07:59, Nitin Gupta wrote:
If we get no perf. problems with this patch, then I beleive it is now
suitable to inclusion in mainline. Further cleanups and optimizations
can surely be done after that. It's still just ~500 LOC.
Before LZO code is sent to Linus, its selection in
On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
[...]
Can anyone do timing measurement in kernel space only. This will
eliminate all possible problems w.r.t usespace testing. I tried doing
the same using get_jiffies_64() across calls to compressor in the
'compress-test' module but this is
Hi,
This is kernel port of LZO1X-1 compressor and LZO1X decompressor (safe
version only).
--
If we get no perf. problems with this patch, then I beleive it is now
suitable to inclusion in mainline. Further cleanups and optimizations
can surely be done after that. It's still just ~500 LOC.
--
*
Hi,
This is kernel port of LZO1X-1 compressor and LZO1X decompressor (safe
version only).
--
If we get no perf. problems with this patch, then I beleive it is now
suitable to inclusion in mainline. Further cleanups and optimizations
can surely be done after that. It's still just ~500 LOC.
--
*
On 5/28/07, Nitin Gupta [EMAIL PROTECTED] wrote:
[...]
Can anyone do timing measurement in kernel space only. This will
eliminate all possible problems w.r.t usespace testing. I tried doing
the same using get_jiffies_64() across calls to compressor in the
'compress-test' module but this is
On 28 May 2007, at 07:59, Nitin Gupta wrote:
If we get no perf. problems with this patch, then I beleive it is now
suitable to inclusion in mainline. Further cleanups and optimizations
can surely be done after that. It's still just ~500 LOC.
Before LZO code is sent to Linus, its selection in
On 5/28/07, Michael-Luke Jones [EMAIL PROTECTED] wrote:
On 28 May 2007, at 07:59, Nitin Gupta wrote:
If we get no perf. problems with this patch, then I beleive it is now
suitable to inclusion in mainline. Further cleanups and optimizations
can surely be done after that. It's still just ~500
On 28 May 2007, at 13:09, Nitin Gupta wrote:
This means:
1) Options in lib/Kconfig hidden (selectable by drivers as required)
LZO as hidden option has no practical sense. Although LZO should be
auto-selected when some dependent project is selected (e.g. reieser4)
- there should be separate
On 5/28/07, Michael-Luke Jones [EMAIL PROTECTED] wrote:
No, LZO as a visible option makes no practical sense. Why would
anyone want to build LZO into a kernel when there are no in-kernel
users of the code?
Agreed. It should be a auto-selected hidden config option.
-
To unsubscribe from this
12 matches
Mail list logo
