Since the content of irqnr.h is entirely wrapped in a __KERNEL__ test,
drop exporting it, and remove the single include of that header from
random.h.
Signed-off-by: Robert P. J. Day
---
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index fa21760..b9de555 100644
--- a/include/linux
Given that the entire drivers/acorn/block/ directory no longer exists
(which included fd1772.c), there seems to be little reason to keep
this unreferenced header file.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/include/linux/fd1772.h b/include/linux/fd1772.h
d
e of these headers, but is it really the
responsibility of the kernel to be a helpful storage centre to make
userspace programming easier? just curious. (that's not the only
header file like that.)
rday
--
============
Robert P. J. Day
L
rc1?
rday
--
========
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook:http://crashcour
* superfluous.
rday
--
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook:http://crashcourse.ca/wiki/index
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
--
To
On Wed, 13 Feb 2008, Paul Mundt wrote:
> On Wed, Feb 13, 2008 at 03:56:34AM -0500, Robert P. J. Day wrote:
> > latest output here, sorted by architecture:
> >
> > http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables
> >
> > as always, there will pro
variables
rday
--
============
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo,
On Wed, 13 Feb 2008, Paul Mundt wrote:
> On Wed, Feb 13, 2008 at 05:54:12AM -0500, Robert P. J. Day wrote:
> > i've also updated the list of what i call "badref" CONFIG variables
> > -- that is, tests of CONFIG_ variables that appear to be undefined
> &g
is not defined
anywhere. you get the idea. there are only a couple dozen of these.
rday
--
============
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http:/
On Wed, 13 Feb 2008, Josh Boyer wrote:
> On Wed, 13 Feb 2008 03:56:34 -0500 (EST)
> "Robert P. J. Day" <[EMAIL PROTECTED]> wrote:
> > now that 2.6.25-rc1 is out, i can start updating the output from
> > my scanning scripts. the first updated output is the li
s scanning happens only once every release,
it's not like it's a burden. and if people want to ignore it, that's
fine, too.
rday
--
Robert P. J. Day
Linux Consulting, T
On Wed, 13 Feb 2008, Sam Ravnborg wrote:
> On Wed, Feb 13, 2008 at 10:07:27AM -0500, Robert P. J. Day wrote:
> > On Wed, 13 Feb 2008, Josh Boyer wrote:
> >
> > > On Wed, 13 Feb 2008 03:56:34 -0500 (EST)
> > > "Robert P. J. Day" <[EMAIL PROTECTED]>
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
--
To unsubscribe from this list: sen
On Wed, 13 Feb 2008, Sam Ravnborg wrote:
> On Wed, Feb 13, 2008 at 10:44:27AM -0500, Robert P. J. Day wrote:
> > On Wed, 13 Feb 2008, Josh Boyer wrote:
> >
> > > OK. Well all of your hits for 405EX, 440GRX, 440SPe, and
> > > WANT_DEVICE_TREE in arch/powerpc
On Sun, 17 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
> Fix goofups of commit 76166952bbc81dda1c8a8c14e75a2aa06f6c052c
> (" is not used by kernel code").
>
> Reported-by: "Robert P. J. Day" <[EMAIL PROTECTED]>
> Signed-off-by: Bartlomiej Zolnierkiewicz &
On Sun, 17 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
> On Sunday 17 February 2008, Adrian Bunk wrote:
> > On Sun, Feb 17, 2008 at 06:40:31PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > On Sunday 17 February 2008, Robert P. J. Day wrote:
> > > > On Sun, 17 Feb 2
On Mon, 18 Feb 2008, [EMAIL PROTECTED] wrote:
> On Sun, 17 Feb 2008 12:17:20 EST, "Robert P. J. Day" said:
>
> > if that header file isn't used by any kernel code, why bother having a
> > check for __KERNEL__ in the first place? it's being exported to
>
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Coo
On Wed, 6 Feb 2008, Harvey Harrison wrote:
> On Wed, 2008-02-06 at 20:54 +0100, Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > On Wednesday 06 February 2008, Robert P. J. Day wrote:
> > >
> > > yes, i realize i'm sounding like a broken record
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Coo
the patch,
unless it's already working its way thru the system.
rday
--
============
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.c
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook:http://crashcourse.ca/wiki/inde
Remove the explicit definition, and subsequent superfluous testing, of
BUILD CRAMDISK.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
is there any point to this brute-force setting anymore? just
curious.
diff --git a/init/do_mounts_rd.c b/init/do_mounts_rd.c
index ed652f4..5
http://www.sunifdef.strudl.org/
that should do for now.
rday
--
============
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://cr
Since defining multi-line macros using statements and declarations in
expressions is fairly common in the kernel, add this to CodingStyle.
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index cb9258b..7eb0734 100644
--- a/Documentation
On Sun, 24 Feb 2008, Jiri Slaby wrote:
> On 02/09/2008 10:45 PM, Robert P. J. Day wrote:
> > Remove the Digi Intl. epca driver for Linux, which is marked as
> > "obsolete."
> >
> > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
> >
>
ported even *if* you select PCI_LEGACY.
i'm guessing that's an oversight but it would certainly suggest that
no one can possibly be using it, no?
rday
--
============
Robert P. J. Day
Linux Consulting, Training and Annoying
.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
i'm not sure what kernel subsystem this falls under. this change
should not affect anything in the kernel, and the corresponding
ioctl.h headers can be tweaked sometime down the road.
diff --git a/include/asm-generic/ioctl.h b/
On Tue, 26 Feb 2008, Adrian Bunk wrote:
> On Mon, Feb 25, 2008 at 05:15:25PM -0500, Robert P. J. Day wrote:
> >
> > it's not just that it falls under the category of PCI "legacy" but,
> > if you look in drivers/pci/search.c near the bottom:
>
de/asm-m32r/processor.h:#define THREAD_SIZE (2*PAGE_SIZE)
include/asm-m68k/page.h:#define THREAD_SIZE (8192)
all other arches seem to define that in their respective
thread_info.h headers.
rday
====
Robert P. J. Day
Linux Cons
ss
*something*.
allowing NULL as a second arg just makes it more visually obvious that
the caller isn't interested in that return value. or is there
something more subtle going on here that i'm not understanding?
rday
--
Robert P. J. Day
Linux Consulting, Training and An
Correct the obvious "copy and paste" errors explaining some of the
"find_next" routines.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
arch/i386/lib/bitops.c|2 +-
arch/x86_64/lib/bitops.c |2 +-
include/asm-i386/bitops.h |5 ++---
3 f
^^^
i thought the recent standard was to use the capitalized form of
"CPU".
rday
--
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
= 64) ? ULLONG_MAX : ((1ULL<<(n))-1))
rday
--
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
=
/boards/stamp.c:#include
arch/blackfin/mach-bf561/boards/cm_bf561.c:#include
=== Missing: include/linux/ust.h ===
drivers/media/video/v4l2-common.c:#include
rday
--
================
Robert P. J. Day
Linux Consulting, Training and Annoying Ker
On Sat, 6 Oct 2007, Mike Frysinger wrote:
> On 10/6/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > the result of running a quick and dirty shell script that
> > locates inclusions of header files under "include/linux" where
> > those header files don&#
hppa-linux-gcc: command not
found
/home/rpjday/k/git/arch/parisc/Makefile:39: *** Sorry, GCC v3.3 or above is
required.. Stop.
rday
--
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantr
On Wed, 10 Oct 2007, Randy Dunlap wrote:
> On Wed, 10 Oct 2007 12:44:58 -0400 (EDT) Robert P. J. Day wrote:
>
> > the final example, parisc, just plain fails:
> >
> > $ make ARCH=parisc headers_install
> > /home/rpjday/k/git/scripts/gcc-version.sh: line 16: hp
led that can target parisc. It
> doesn't seem obvious to me that this should work.
are you claiming that installing arch-specific kernel headers should,
in fact, require an appropriate cross compiler? i wouldn't have
thought so, but i'm willing to be corrected.
rday
--
=
alpha/core_t2.h:#include
... lots more alpha stuff ...
so there does appear to be some precedent for an asm/compiler.h.
for better or worse.
rday
--
Robert P. J. Day
_SUPPORTS_APM_EMULATION
./arch/sh/Kconfig:config SYS_SUPPORTS_APM_EMULATION
./arch/arm/Kconfig:config SYS_SUPPORTS_APM_EMULATION
./arch/powerpc/Kconfig:config SYS_SUPPORTS_APM_EMULATION
so there's a good chance that doing a kernel config with any other
arch than those listed above that supports PM is going to gen
type controls what happens to the kobject when it is
> created and destroyed.
i doubt that. i wouldn't say that the ktype "controls" what happens,
i would say that it "defines" what happens. to control suggests
active participation.
rday
===========
ake some changes to the tree, do a diff, and
submit a patch. but in the beginning, they won't be making commits or
switching branches, etc.
in short, i can see the value of something like a "getting started
with git as a basic user" tutorial. does such a thing exist?
rday
--
======
On Sun, 23 Dec 2007, Jeff Garzik wrote:
> Robert P. J. Day wrote:
> > On Sun, 23 Dec 2007, Jeff Garzik wrote:
> >
> > > Another year, another update! :)
> > >
> > > The kernel hacker's guide to git has received some updates:
> > >
>
On Sun, 23 Dec 2007, Dieter Ries wrote:
> Robert P. J. Day schrieb:
> > just to be clear, i'm not complaining about the quality of the
> > document above, but when i got started with git, what i really
> > wanted was a list of what i (as a simple, non-developer user)
&g
you can get the overall idea. new
sections should be appearing there as the morning progresses.
rday
========
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://cra
tsoever. i
ran modprobe under "strace" and it doesn't appear to make any effort
to check /proc/sys/kernel/modprobe. i even downloaded the source to
the module-init-tools package and scanned the source and ... nothing.
so what's up with that?
rday
===
On Thu, 29 Nov 2007, Alexey Dobriyan wrote:
> On 11/29/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > echo '#! /bin/sh' > /tmp/modprobe
> > echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
> > echo 'exec /s
On Thu, 29 Nov 2007, Alexey Dobriyan wrote:
> On 11/29/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > echo '#! /bin/sh' > /tmp/modprobe
> > echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
> > echo 'exec /s
On Thu, 29 Nov 2007, Kay Sievers wrote:
> On Nov 29, 2007 1:58 PM, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > On Thu, 29 Nov 2007, Alexey Dobriyan wrote:
> >
> > > On 11/29/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > > > echo
# ld -v
> +o Gnu bc 1.06# bc -v
you need bc? for what? i just did a defconfig build for x86 with no
need for bc.
> +o Perl 5.6.0(?)# perl -v
if you mention perl, you should also mention sed and awk, no? and
perha
s_" prefix from all of those
files as well.
rday
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To unsubs
Given that init/Makefile includes initramfs.c in the build only if
CONFIG_BLK_DEV_INITRD is defined, there seems to be no point checking
for it yet again.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
compile-tested on x86.
diff --git a/init/initramfs.c b/init/initramfs.c
ome of the niggling
differences between some of that content between the two files.
rday
========
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://cras
g that @kobj->k_name points to. Otherwise, use the static
> * @kobj->name array.
> */
the comment seems fairly clear -- if the name is sufficiently short,
it's stored in the static array. if not, then it's stored in
dynamically allocated space.
rday
=============
does anyone know what's happened with the KN list? it seems to have
gone utterly dead for the last day or so.
rday
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
On Mon, 3 Dec 2007, Greg KH wrote:
> On Tue, Dec 04, 2007 at 01:50:53AM -0500, Robert P. J. Day wrote:
> > On Tue, 4 Dec 2007, Dave Young wrote:
> >
> > > Hi,
> > > Does the KOBJ_NAME_LEN really means the limit of kobject name length?
> > > seems not .
Adjustments:
auxvec.h, i2c-dev.h and vt.h *should* be unifdef'ed
i2o-dev.h does not need unifdef'ing
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 37bfa19..6a7a525 100644
--- a/include/linux/Kbui
RCH=powerpc headers_install/headers_check
we've sort of had this discussion before where, IIRC, you should be
able to generate the appropriate arch-specific headers without having
the corresponding toolchain, no? so why can&
On Wed, 21 Nov 2007, Andrew Morton wrote:
> On Wed, 21 Nov 2007 03:52:08 -0500 (EST) "Robert P. J. Day" <[EMAIL
> PROTECTED]> wrote:
... snip ...
> > i'm sure i'm going to humiliate myself for asking this, but shouldn't
> > i be able to reproduce
==========
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To unsubscribe from this list: send the line
r example.
rday
--
============
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
nclude/linux/netlink.h
sunifdef: /home/rpjday/k/git/include/linux/netlink.h: line 205:
warning 0x02070: Garbage following preprocessor directive in "#if PAGE_SIZE <
8192UL" (#if line 152 depth 2)
i'm guessing it's that "UL" suffix it doesn't like.
rday
rpmbuild" on the
machine, would it not?
rday
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
=
memset(n, 0, sz);
> + n = kzalloc(sz, GFP_KERNEL);
> + else {
> + if (hashdist)
i believe the more common standard for the above is:
else if (hashdist) {
to reduce the level of overall indentation, no?
rday
=
oppy about it. unless you're
prepared to guarantee that there will never be another call to
setup_dev() from elsewhere.
rday
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
=
On Mon, 26 Nov 2007, Joonwoo Park wrote:
> 2007/11/26, Robert P. J. Day <[EMAIL PROTECTED]>:
> > i'm not sure the above is a safe thing to do, as you're zeroing that
> > area, then making a function call and assuming, upon entry to the
> > function call, tha
On Mon, 26 Nov 2007, Joonwoo Park wrote:
> 2007/11/26, Robert P. J. Day <[EMAIL PROTECTED]>:
> > i realized that. but all you can say is that only amb_init() calls
> > setup_dev() *currently*. when you're not looking, someone else might
> > (for whatever reason)
On Mon, 26 Nov 2007, Ray Lee wrote:
> On Nov 26, 2007 12:54 AM, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > on current systems, "rpm" no longer has build capability and will
> > fail thusly:
> >
> > rpm --target i386 -ta ../kernel-2.6.24rc3g2ffbb8
On Mon, 26 Nov 2007, Robert P. J. Day wrote:
> On Mon, 26 Nov 2007, Ray Lee wrote:
>
> > On Nov 26, 2007 12:54 AM, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > > on current systems, "rpm" no longer has build capability and will
> > > fail thusl
On Mon, 26 Nov 2007, Jan Engelhardt wrote:
>
> On Nov 26 2007 06:58, Ray Lee wrote:
> >On Nov 26, 2007 12:54 AM, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> >> on current systems, "rpm" no longer has build capability and will
> >> fail thu
On Mon, 26 Nov 2007, Jan Engelhardt wrote:
>
> On Nov 26 2007 10:53, Robert P. J. Day wrote:
> >
> >>>Only on current machines. You'd break building kernel RPMs on older
> >>>systems that don't have rpmbuild installed.
> >>
> >>
On Mon, 26 Nov 2007, Jan Engelhardt wrote:
>
> On Nov 26 2007 11:13, Robert P. J. Day wrote:
> >> >>>Only on current machines. You'd break building kernel RPMs on older
> >> >>>systems that don't have rpmbuild installed.
> >> &g
ally
without kbuild is just making this way more difficult than it has to
be.
rday
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Use the recommended form of "<>" to include linux header files, and
move those includes up to join the rest of the linux includes.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
outside of the UML stuff, there are precious few examples of including
headers out
directory tree?
i would try "partprobe".
rday
--
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://cr
kernel, but not *logical* partition changes. or something sort of
like that.
rday
--
========
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page:
Given a number of places in the tree that need to calculate this value
explicitly, might as well just create a macro for it.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
run-time tested for the first several values. note that this macro
is defined strictly in terms of ro
On Sun, 11 Nov 2007, Randy Dunlap wrote:
> On Sat, 10 Nov 2007 22:53:36 -0500 (EST) Robert P. J. Day wrote:
> >
> > +/**
> > + * order_base_2 - calculate the (rounded up) base 2 order of the argument
> > + * @n - parameter
>
> * @n: argument
>
> (mostl
Given a number of places in the tree that need to calculate this value
explicitly, might as well just create a macro for it.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
run-time tested for the first several values. note that this macro
is defined strictly in terms of ro
t have to adhere to . It might use
> > instead, or whatever.
>
> Every C compiler has .
i'm assuming you mean , no?
rday
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
W
duleparam.h, there may come a day when
those header files are refactored to actually make sense, at which
point all those missing moduleparam.h inclusions will cause all sorts
of bad things to happen.
rday
p.s. i tried that cleanup once. it got ugly in a hurry.
--
==============
t's someone else's decision, not mine. i'm just
reporting on how quickly things got unpleasant when *i* tried to do
something with this once upon a time.
rday
--
=
since this topic came up recently:
http://www.crashcourse.ca/wiki/index.php/Module.h_and_moduleparam.h
rday
p.s. we had this discussion some time back but it didn't go anywhere.
--
Robert P. J. Day
Linux Consu
leanable without massive disruption.
rday
--
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To
C_INC
>>>>> RAM16BIT
>>>>> RAM32BIT
>>>>> RAM8BIT
>>>>> ROMFS_FROM_ROM
>>>>> WILDFIREMOD
mips
>>>>> 64BIT_CONTEXT
>>>>> ACER_PICA_61
>>>>> CPU_SB1_PASS_2_112x
>>>>> CPU_SB1_PASS_2_1250
>>>>> CPU_SB1_PASS_3
&g
On Mon, 19 Nov 2007, Paul Mundt wrote:
> On Fri, Nov 16, 2007 at 06:15:48AM -0500, Robert P. J. Day wrote:
> > sh64
> > >>>>> DEVICE_MEMORY_START
> > >>>>> FLASH_MEMORY_START
> > >>>>> HDSP253_LED
> > >
ef CONFIG_ETRAXFS_SIM
include/asm-cris/arch-v32/page.h:14:#ifndef CONFIG_ETRAXFS_SIM
>>>>> SHARE_SHLIB_CORE
include/asm-cris/eshlibld.h:44: Mainly depends on the config macro
CONFIG_SHARE_SHLIB_CORE, but it is
include/asm-cris/eshlibld.h:49: && !defined(CONFIG_SHARE_
config files.
rday
p.s. perhaps one of the CRIS folks could verify that those variables
are, in fact, unused, so i know i haven't screwed something up
horribly.
--
================
Robert P. J. Day
Linux Consulting, Training and Annoyi
rather than waste mailing list bandwidth, a list of unused CONFIG
variables (a work in progress as we speak):
http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables
rday
--
Robert P. J. Day
Linux Consulting
at correct? am i just misreading something? or
could the comment have been a bit clearer?
rday
--
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Water
On Sat, 27 Oct 2007, Haavard Skinnemoen wrote:
> On Sat, 27 Oct 2007 07:39:40 -0400 (EDT)
> "Robert P. J. Day" <[EMAIL PROTECTED]> wrote:
>
> > note how the comment says that the next entry will "usually" be
> > sg+1, "but" not if it&#x
ving them scattered across the first 100 lines or
so? it would just make them easier to find when you're perusing the
code.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
s of CONFIG_CONFIG_X? Doesn't seem like a
> terribly sensible name...
there used to be:
http://lists.linuxcoding.com/kernel/2006-q1/msg18685.html
but that was just the one, and it's gone now.
rday
--
Robert P. J.
To be consistent with other architectures, these two DMA macros should
be defined in scatterlist.h as opposed to dma-mapping.h
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
if david prefers to handle this because he wants to do something
differently, that's cool.
On Mon, 29 Oct 2007, Robert P. J. Day wrote:
>
> To be consistent with other architectures, these two DMA macros should
> be defined in scatterlist.h as opposed to dma-mapping.h
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
whoops, just noticed that i hadn't
On Mon, 29 Oct 2007, David Howells wrote:
> Robert P. J. Day <[EMAIL PROTECTED]> wrote:
>
> > To be consistent with other architectures, these two DMA macros should
> > be defined in scatterlist.h as opposed to dma-mapping.h
>
> Why have you discarded the comment?
To be consistent with other architectures, these two DMA macros should
be defined in scatterlist.h as opposed to dma-mapping.h
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
include/asm-frv/dma-mapping.h | 10 --
include/asm-frv/scatterlist.h | 10 ++
2
Add some macros to to make the bit manipulation
more readable, and expand on some of the documentation.
This patch incorporates content from Cyrill Gorcunov
<[EMAIL PROTECTED]> as well.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
compile-tested with "make defc
1 - 100 of 924 matches
Mail list logo
