(i'm not *trying* to belabour this issue ... i am merely succeeding)
On Sat, 16 Dec 2006, Tim Schmielau wrote:
> On Sat, 16 Dec 2006, Robert P. J. Day wrote:
...
> > ... it's amazing the variation that you find beyond the obvious:
> >
> > $ grep -
CC drivers/connector/connector.o
drivers/connector/connector.c: In function 'cn_call_callback':
drivers/connector/connector.c:138: error: 'struct work_struct' has no member
named 'management'
drivers/connector/connector.c:138: error: 'struct work_struct' has no member
named 'management'
m
as with ARRAY_SIZE(), there are a number of places (mercifully, far
fewer) that recode what could be done with the FIELD_SIZEOF() macro in
kernel.h.
i wrote a short script to handle that and this is the result (after
a minor amount of hand tweaking):
arch/m68k/kernel/signal.c
so here's the end result of my experiment to replace unnecessary
code snippets with an invocation of the ARRAY_SIZE() macro from
include/linux/kernel.h. i've attached the script that i ran on the
entire tree, then (after adding al viro's connector patch), did:
$ make allyesconfig # for the
On Sun, 17 Dec 2006, Randy Dunlap wrote:
> On Sun, 17 Dec 2006 13:13:59 -0500 (EST) Robert P. J. Day wrote:
>
> >
> > so here's the end result of my experiment to replace unnecessary
> > code snippets with an invocation of the ARRAY_SIZE() macro from
> > inc
Change the explicit code in the relocs.c file to use ARRAY_SIZE()
and add a definition of ARRAY_SIZE() since this is a userspace program
and wouldn't include kernel.h.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
As Randy Dunlap pointed out, the relocs.c file is a use
On Sat, 16 Dec 2006, Stefan Richter wrote:
> Robert P. J. Day wrote on 2006-12-14:
> > i've posted on this before so here's a slightly-updated patch
> > that uses the kbuild "menuconfig" feature to make numerous entries
> > under the Device drivers menu
On Sat, 16 Dec 2006, Stefan Richter wrote:
> Robert P. J. Day wrote on 2006-12-14:
> > i've posted on this before so here's a slightly-updated patch that
> > uses the kbuild "menuconfig" feature to make numerous entries under
> > the Device drivers menu
Remove Kconfig comparisons of the form FUBAR || FUBAR=n, since they
appear to be superfluous.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
based on what i read in kconfig-language.txt, it would *appear* that
those comparisons are redundant, but i'm willing to b
On Mon, 18 Dec 2006, Russell King wrote:
> On Mon, Dec 18, 2006 at 05:14:01AM -0500, Robert P. J. Day wrote:
> > Remove Kconfig comparisons of the form FUBAR || FUBAR=n, since they
> > appear to be superfluous.
>
> config FOO
> tristate 'foo'
>
On Mon, 18 Dec 2006, Jan Engelhardt wrote:
>
> On Dec 18 2006 09:57, Steven Whitehouse wrote:
> > config GFS2_FS_LOCKING_DLM
> > tristate "GFS2 DLM locking module"
> >-depends on GFS2_FS
> >+depends on GFS2_FS && NET && INET && (IPV6 || IPV6=n)
>
> What is this supposed to do? IPV6 ||
On Mon, 18 Dec 2006, Stefan Richter wrote:
> Robert P. J. Day wrote:
> [...]
> > in any event, as i mentioned earlier, i'm just trying to find a
> > way to make the menu entries more obvious and more easily
> > selectable, without having to enter each submenu
Remove from the documentation the notion of using "depends" rather
than "depends on" in Kconfig files.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
given that there are only three Kconfig files left that still use
"depends" rather than "
On Mon, 18 Dec 2006, Adrian Bunk wrote:
> On Mon, Dec 18, 2006 at 10:40:25AM -0500, Robert P. J. Day wrote:
> >
> > Remove from the documentation the notion of using "depends" rather
> > than "depends on" in Kconfig files.
> >
> &
Remove the note in the documentation that suggests people can use
"requires" for dependencies in Kconfig files.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
at this point, AFAICT, all Kconfig files now use "depends on"
exclusively, except for three tha
Add a new section to the CodingStyle file, encouraging people not to
re-invent available kernel macros such as ARRAY_SIZE(),
FIELD_SIZEOF(), min() and max(), among others.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
NOTE: at the moment, there is not a single invocation
Replace kmalloc() + memset() pairs with the appropriate kzalloc()
calls.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
i could have sworn i submitted this patch a while back but it
doesn't seem to have been applied. it's possible it's still in the
queue s
On Mon, 18 Dec 2006, Erik Mouw wrote:
> On Mon, Dec 18, 2006 at 12:43:35PM -0500, Robert P. J. Day wrote:
> > Add a new section to the CodingStyle file, encouraging people not to
> > re-invent available kernel macros such as ARRAY_SIZE(),
> > FIELD_SIZEOF(), min() an
Use the appropriate logging macro for the priority level for that
printk call.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
this appears to be the only instance in the entire tree of
hard-coding the log level in a printk.
diff --git a/arch/ppc/syslib/m8260_pci_erratum
On Mon, 18 Dec 2006, Adrian Bunk wrote:
> On Mon, Dec 18, 2006 at 11:41:59AM -0500, Robert P. J. Day wrote:
> >
> > Remove the note in the documentation that suggests people can use
> > "requires" for dependencies in Kconfig files.
> >...
>
> Consideri
On Mon, 18 Dec 2006, Adrian Bunk wrote:
> On Mon, Dec 18, 2006 at 01:46:27PM -0500, Robert P. J. Day wrote:
> > p.s. i didn't look closely enough to see if your patch took out
> > support for both "depends" *and* "requires". at this point,
> > neit
for the last couple of days, i've been unable to pull from linus'
2.6 repository. i consistently get:
$ git pull
fatal: unexpected EOF
Fetch failure:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
No changes.
even after several retries. i can clone it from scratch, i j
Change the two remaining instances in the tree of kcalloc(1,...) to
the corresponding kzalloc() call.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index fb96144..5ebdd8a 100644
--- a/sound/p
Get rid of the remaining obvious pointer casts of all k[cmz]alloc
calls, and do a little whitespace cleanup on the result, based on the
CodingStyle file.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
since this patch hits a range of files, i'm just throwing it out
t
On Tue, 19 Dec 2006, Jan Engelhardt wrote:
> > Get rid of the remaining obvious pointer casts of all k[cmz]alloc
> >calls, and do a little whitespace cleanup on the result, based on the
> >CodingStyle file.
>
> >-struct intmem_allocation* alloc =
> >- (struct intmem_alloc
just for fun, i threw the following together to peruse the tree (or
any subdirectory) and look for stuff that violates the CodingStyle
guide. clearly, it's far from complete and very ad hoc, but it's
amusing. extra searches happily accepted.
rday
#!/bin/sh
DIR=${1-.}
echo -e "\n= Dep
Remove the last use of kmem_cache_t and the deprecated typedef.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
without looking too deeply into it, it looks like the last
references to kmem_cache_t can be removed, although there are still
going to be online web pages that re
Replace appropriate pairs of "kmem_cache_alloc()" + "memset(0)" with
the corresponding "kmem_cache_zalloc()" call.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
Someone might want to check this carefully -- it's been a long day
and I mig
On Tue, 19 Dec 2006, David Rientjes wrote:
> On Tue, 19 Dec 2006, Robert P. J. Day wrote:
>
> > diff --git a/include/asm-um/thread_info.h b/include/asm-um/thread_info.h
> > index 261e2f4..e43c2dd 100644
> > --- a/include/asm-um/thread_info.h
> > +++ b/include/asm
On Tue, 19 Dec 2006, David Rientjes wrote:
> On Tue, 19 Dec 2006, Robert P. J. Day wrote:
>
> > that sounds reasonable but, as i've mentioned before, many of the
> > sizable cleanups i've submitted are produced by a simple script,
> > which is written to process
all right, i may have misread what's going on with
kmem_cache_alloc() and kmem_cache_zalloc(), and my earlier submission
may be entirely nonsense, since it involved transformations like this:
* it with privilege level 3 because the IVE uses non-privileged
accesses to these
*
given that "get_free_page" is dead:
http://www.ussg.iu.edu/hypermail/linux/kernel/0210.1/1471.html
maybe someone wants to remove the final references to it from the
tree:
$ grep -rw get_free_page *
arch/sparc/kernel/ioport.c: * zait:
remap_it_my_way(virt_to_phys(get_free_page()))
arch/sparc
On Thu, 4 Jan 2007, Thomas Hisch wrote:
> On Sun, Dec 31, 2006 at 03:55:22PM -0500, Robert P. J. Day wrote:
> > @@ -1810,8 +1809,7 @@ lcs_get_frames_cb(struct lcs_channel *channel, struct
> > lcs_buffer *buffer)
> > LCS_DBF_TEXT(4, trace, "-eiogpkt
On Fri, 5 Jan 2007, Ahmed S. Darwish wrote:
> Remove unnecessary kmalloc casts in drivers/char/tty_io.c
rather than remove these casts a file or two at a time, why not just
do them all at once and submit a single patch? there aren't that many
of them:
grep -Er "\([^\)\*]+\*\) ?k[cmz]alloc ?\(
On Fri, 5 Jan 2007, Ahmed S. Darwish wrote:
> On Fri, Jan 05, 2007 at 09:10:01AM +0100, Rolf Eike Beer wrote:
> > Ahmed S. Darwish wrote:
> > > Remove unnecessary kmalloc casts in drivers/char/tty_io.c
> > >
> > > Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]>
> >
> > if (!*ltp_loc) {
> > -
On Fri, 5 Jan 2007, Alan wrote:
> > represents a kmalloc->kzalloc cleanup (there's lots of those), and
> > also see if you can replace one of these:
> >
> > sizeof(struct blah)
> >
> > with one of these:
> >
> > sizeof(*blahptr)
>
> Patches that do this will get rejected by the tty maintainer
Delete the few remaining unnecessary calls to memset(0) after a call
to kzalloc().
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
AFAICT, these are the few remaining instances of this. if you're
aware of any others, let me know and i can resubmit a revised patch.
Explain a couple of the most common errors in kernel-doc usage.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
seems useful to emphasize these issues since they occur occasionally
in the source.
diff --git a/Documentation/kernel-doc-nano-HOWTO.txt
b/Documentation/kernel-do
On Sat, 6 Jan 2007, Ahmed S. Darwish wrote:
> > On Fri, Jan 05, 2007 at 09:10:01AM +0100, rday wrote:
> > > Ahmed S. Darwish wrote:
> > > Remove unnecessary kmalloc casts in drivers/char/tty_io.c
> > > Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]>
> >
> > rday
> >
> > p.s. just FYI, i have a p
i notice, in kernel/timer.c, the kernel-doc comment for
do_gettimeofday():
NOTE: Users should be converted to using get_realtime_clock_ts()
does this mean that do_gettimeofday() should be officially deprecated?
that *seems* to be what that note is suggesting.
in any event, there is no "ge
in include/linux/hrtimer.h, we read:
* The hrtimer structure must be initialized by init_hrtimer_#CLOCKTYPE()
what means that last part, "init_hrtimer_#CLOCKTYPE()"? i'm not aware
of any such routine. i'm aware only of init_hrtimers_cpu().
rday
p.s. besides, that "#" messes up the kerne
On Sat, 6 Jan 2007, Ahmed S. Darwish wrote:
> Hi all,
> I'm not able to find the DAC960 block driver maintainer. If someones knows
> please reply :).
>
> A patch to switch kmalloc->kzalloc and to clean unneeded kammloc,
> pci_alloc_consistent casts
>
> Signed-off-by: Ahmed Darwish <[EMAIL PROTECTE
according to the kernel-doc HOWTO, the following should be
"highlighted" in some way if found in the extractable documentation of
your source file:
'&struct_name' - name of a structure (up to two words including 'struct')
but examples of that, at least in the HTML, are simply printed in
regu
aces
* reword some text for clarity
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
this should give randy something to do.
include/asm-i386/atomic.h |4 ++--
include/asm-i386/bitops.h |4 ++--
include/linux/init.h |2 +-
include/linux/kfifo.h |6 +++
On Sun, 7 Jan 2007, Randy Dunlap wrote:
> On Sun, 7 Jan 2007 20:12:42 +0100 Segher Boessenkool wrote:
>
> > There's an extra tab in that last line. Could you also
> > please fix the indenting (use a tab, not spaces) -- I know
> > it was there originally, but since there are only a few
> > lines i
Remove a couple final references to the obsolete verify_area() call,
which was long ago replaced by access_ok().
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
it *appears* that these last two references can be removed, unless
there's something really strange i'm
On Mon, 8 Jan 2007, Sumit Narayan wrote:
> Asking for KFREE is as silly as asking for a macro to check if
> kmalloc succeeded for a pointer, else return ENOMEM.
>
> #define CKMALLOC(p,x) \
> do { \
> p = kmalloc(x, GFP_KERNEL); \
> if(!p) return -ENOMEM; \
>} while(0)
oooh
just to stir the pot a bit regarding the discussion of the two
different ways to define macros, i've just noticed that the "({ })"
notation is not universally acceptable. i've seen examples where
using that notation causes gcc to produce:
error: braced-group within expression allowed only in
Clean up some PowerPC source files to use the canonical alignment
macros from kernel.h, and add an ALIGN_DOWN() macro to kernel.h for
symmetry.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
there doesn't seem to be any compelling reason for the PPC code to
need to def
On Tue, 9 Jan 2007, Paul Mackerras wrote:
> Robert P. J. Day writes:
>
> > Clean up some PowerPC source files to use the canonical alignment
> > macros from kernel.h, and add an ALIGN_DOWN() macro to kernel.h for
> > symmetry.
>
> [snip]
>
> > and, no
Delete the definition of the unused FIND_FIRST_BIT() macro.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
this macro seems safely deletable, given that there is no other
reference to that macro anywhere in the entire source tree and,
besides, one should use find_fir
On Tue, 9 Jan 2007, linux-os (Dick Johnson) wrote:
>
> On Tue, 9 Jan 2007, Stefan Richter wrote:
>
> > Robert P. J. Day wrote:
> >> just to stir the pot a bit regarding the discussion of the two
> >> different ways to define macros,
> >
> > You me
On Wed, 10 Jan 2007, linux-os (Dick Johnson) wrote:
>
> On Wed, 10 Jan 2007, Robert P. J. Day wrote:
> > just FYI, the reason i brought this up in the first place is that
> > i noticed that the ALIGN() macro in kernel.h didn't verify that
> > the alignment value w
based on randy's earlier email, here's an updated model for a patch
that adds a couple selectors to the Device Drivers menu, one for a
boolean MPT, and the other for a tristate MTD. it *seems* to work.
(one improvement that *could* be made would be to also edit the MTD
sub-Kconfig files and rem
i'm thinking that the kconfig structure doesn't really need to
support all three of these dependency directives for Kconfig files. a
quick occurrence count:
"depends on": 4421
"depends":45
"requires": 0
under the circumstances, why not just standardize on "depends on"
everywhere
Standardize the miniscule percentage of occurrences of "depends" in
Kconfig files to "depends on", and update kconfig-language.txt to
reflect that.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
This patch doesn't address the redundancy of "
perhaps a silly question, but:
$ grep -r "DMA_IS_DMA32" *
arch/ia64/defconfig:CONFIG_DMA_IS_DMA32=y
arch/ia64/configs/sim_defconfig:CONFIG_DMA_IS_DMA32=y
arch/ia64/configs/zx1_defconfig:CONFIG_DMA_IS_DMA32=y
arch/ia64/configs/tiger_defconfig:CONFIG_DMA_IS_DMA32=y
arch/ia64/configs/bigsur_defcon
Remove the obsolete CONFIG_DMA_IS_DMA32 entries from the various
"defconfig" files under arch/ia64.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
arch/ia64/configs/bigsur_defconfig|1 -
arch/ia64/configs/gensparse_defconfig |1 -
arch/ia64/confi
On Tue, 28 Nov 2006, Adrian Bunk wrote:
> On Mon, Nov 27, 2006 at 04:37:35PM -0500, Robert P. J. Day wrote:
> >
> > Remove the obsolete CONFIG_DMA_IS_DMA32 entries from the various
> > "defconfig" files under arch/ia64.
> >...
>
> I do not like this
not like it's a big deal, but there's a minor incongruity between
the default values for LOG_BUF_SHIFT for IA64 depending on whether
you're configuring for the first time or not.
if i'm configuring with a fresh tree for the first time (so that
there's no .config file) and i run:
$ make ARC
On Tue, 28 Nov 2006, Arjan van de Ven wrote:
> > ...
> >
> > is it worth trying to bring the Kconfig.debug default values into
> > line with the defconfig file values, to avoid any possible confusion?
>
> I don't think so. defconfig is just there to get some working
> system. You should really p
i noticed that, when i generate the sanitized headers with "make
headers_install", there are still a number of headers files that are
installed with variations on "#ifdef __KERNEL__".
i always thought the fundamental property of sanitized headers was
to be compatible with glibc and have no tr
On Thu, 30 Nov 2006, Alexey Dobriyan wrote:
> On 11/30/06, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > i noticed that, when i generate the sanitized headers with "make
> > headers_install", there are still a number of headers files that are
> >
Add 3 more files to get "unifdef"ed when creating sanitized headers
with "make headers_install".
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index a1155a2..b6bc50c 100644
--- a/include/linux/
has there been a change in the last few days involving whether the
kernel option CONFIG_LOCALVERSION_AUTO appends the first part of $(git
rev-parse HEAD) to the kernel uname?
i could have *sworn* that, only a few days ago, i could configure
and build a new kernel with a uname release of somet
i'm sure there's a simpler way to write this:
include/linux/soundcard.h:
#if (!defined(__KERNEL__) && !defined(KERNEL) && !defined(INKERNEL) &&
!defined(_KERNEL)) ||
defined(USE_SEQ_MACROS)
__KERNEL__ versus KERNEL versus INKERNEL versus _KERNEL? surely,
those can't *all* be necessary. o
On Fri, 1 Dec 2006, Robert P. J. Day wrote:
> has there been a change in the last few days involving whether the
> kernel option CONFIG_LOCALVERSION_AUTO appends the first part of
> $(git rev-parse HEAD) to the kernel uname?
>
> i could have *sworn* that, only a few da
*appears* that what the programmer is trying to do is just initialize
the first element, not all of them -- regardless of the actual effect.
rday
--
============
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
eciate, is somewhat misleading since
some of the parms are relevant only for LILO-based systems. anyway,
is there a standard for all of this?
--
========
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pe
1B-blocks Used Available Use% Mounted on
> /dev/sdb 5999417057280 1908287229952 4091129827328 32%
> /storage/disk1
>
> (Ok here I have 68% free space on our 5.5TB device)
$ df -i
rday
--
============
Robert P.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
this appears to be the final occurrence of that deprecated call in
the entire tree which suggests that, if you're not concerned about
out-of-tree modules, that definition could also be removed from
include/linux/highmem.h:
st
rrent
implementation of semaphores is entirely superfluous. but surely it
isn't possible to replace all semaphores with either mutexes or
completions, is it?
rday
--
============
Robert P. J. Day
Linux Consulting, Training and Anno
On Sat, 23 Jun 2007, Arnd Bergmann wrote:
> On Saturday 23 June 2007, Robert P. J. Day wrote:
> > On Fri, 22 Jun 2007, Arnd Bergmann wrote:
> > >
> > > yes, but you should not. The use of semaphores is not
> > > recommended for new code, it should be rep
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> Hi Robert, Arnd,
>
> On 6/23/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> > On Saturday 23 June 2007, Robert P. J. Day wrote:
> > > On Fri, 22 Jun 2007, Arnd Bergmann wrote:
> > > >
> > > >
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> On 6/23/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > hang on, how is that true? as i read it, mutexes are more than
> > just binary semaphores -- they have additional restrictions that
> > regular semaphores d
iven both mutexes and completions, whether the general semantics
of semaphores can be tightened up at all. just curious.
rday
--
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, C
Just following the advice in the comments, update the alignment when
4K stacks are selected, since gcc 3.0 shouldn't be an issue anymore.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
arch/i386/kernel/irq.c |8 ++--
arch/sh/kernel/irq.c |8 ++--
2 files
On Sun, 24 Jun 2007, Andrew Morton wrote:
> On Sun, 24 Jun 2007 15:21:37 -0400 (EDT) "Robert P. J. Day" <[EMAIL
> PROTECTED]> wrote:
>
> > arch/i386/kernel/irq.c |8 ++--
> > arch/sh/kernel/irq.c |8 ++--
>
> These two files are
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
it's not clear from MAINTAINERS who's responsible for something this
generic.
diff --git a/arch/i386/kernel/irq.c b/arch/i386/kernel/irq.c
index d2daf67..504f134 100644
--- a/arch/i386/kernel/irq.c
+++ b/arch/i
ready well documented here:
http://fsdev.net/wiki/index.php?title=Power_of_2_stuff
and it's unlikely that you'd get a big patch in that tries to do all
of that at once. it's much easier to do it a subsystem at a time.
rday
p.s. that wiki page could probably use some updating.
--
========
g
the "||" operator. but that's being admittedly nitpicky.
rday
--
============
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CA
xed that.
rday
--
============
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list
#x27;t, it's
> generally a long-pipeline operation, right?
i was *just* about to mention somthing of the sort, but probably not
as succinctly.
rday
--
============
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
given that there aren't any other references to this macro anywhere
in the tree, i'm just *guessing* it may not have any further value.
diff --git a/include/linux/init.h b/include/linux/init.h
index 56ec4c6..5b52853 1006
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 4c715a7..1f16787 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1846,7 +1846,7 @@ W:http://www.openib.org/
T: git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.
On Fri, 6 Jul 2007, Stefan Richter wrote:
> Robert P. J. Day wrote:
> > --- a/arch/i386/kernel/io_apic.c
> > +++ b/arch/i386/kernel/io_apic.c
> > @@ -353,7 +353,7 @@ static void set_ioapic_affinity_irq(unsigned int irq,
> > cpumask_t cpumask)
> >
On Fri, 6 Jul 2007, Randy Dunlap wrote:
> On Fri, 6 Jul 2007 06:24:20 -0400 (EDT) Robert P. J. Day wrote:
>
> >
> > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
> >
> > ---
> >
> > diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
>
ct to whether it's worth
investing any time in doing cleanup on it and ripping out unreferenced
content?
thanks.
rday
--
========
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CA
and do_select(), if anyone thinks
it's worth looking at.
rday
--
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.p
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
the current layout of profiling configuration is a bit of a mess, so
this patch tries to make things uniform across all architectures.
1) it's pointless having some arches define profiling as a separate
menu while other
It makes more sense to make instrumentation support experimental on a
case-by-case basis.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
arch/i386/Kconfig|1 -
arch/ia64/Kconfig|1 -
arch/powerpc/Kconfig |1 -
arch/sparc/Kconfig |1 -
arch/sparc64/K
ubdirectory, or something similar.
rday
--
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
==
On Fri, 6 Jul 2007, Dr. David Alan Gilbert wrote:
> * Robert P. J. Day ([EMAIL PROTECTED]) wrote:
>
> > and if that happens, then the config variables defined in
> > drivers/acorn/block/Kconfig:
> >
> > config BLK_DEV_FD1772
> > config BLK_DEV_MFM
On Tue, 10 Jul 2007, Stefan Richter wrote:
> Robert P. J. Day wrote:
> > 2) given how long profiling has been around, it's just as pointless to
> > keep categorizing it as EXPERIMENTAL, so drop all EXPERIMENTAL labels
> > and dependencies.
>
> Only because somet
On Sun, 8 Jul 2007, Oleg Nesterov wrote:
> Robert P. J. Day wrote:
> >
> > as i understand it, schedule_timeout() should always be called with
> > a current->state of TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE, no?
>
> No.
>
> Yes, it is pointless to call sc
(((dir) << _IOC_DIRSHIFT) | \
--
============
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
sorry, it's not clear from MAINTAINERS who the generic ATA contact
person is.
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index fa1c22c..192e95f 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/l
sorry, that was a duplicate of a patch submission from a couple
months back. please ignore.
rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please rea
f kernel internal
> +structures, the sysfs interface can not provide a stable interface eighter,
either
...
you might want to hold off on that patch for a few minutes. :-)
rday
--
Robert
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/drivers/block/umem.c b/drivers/block/umem.c
index 6f5d620..62c9d08 100644
--- a/drivers/block/umem.c
+++ b/drivers/block/umem.c
@@ -105,12 +105,6 @@ struct cardinfo {
unsigned long csr_base;
unsigne
401 - 500 of 924 matches
Mail list logo
