On Jan 20 2008 20:48, Rusty Russell wrote:
>+ */
>+#define kthread_create(threadfn, data, namefmt...) ({ \
>+ int (*_threadfn)(typeof(data)) = (threadfn);\
>+ __kthread_create((void *)_threadfn, (data), namefmt); \
>+})
If you have namefmt... you need that varagrs
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
sound/oss/i810_audio.c|4 ++--
sound/oss/swarm_cs4297a.c |4 ++--
sound/oss/trident.c |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/sound/oss/i810_audio.c b/sound/oss/i810_audio.c
index f
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/proc.c |2 +-
arch/x86/kernel/setup_64.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 3900e46..0282132 100644
--- a/ar
Hi,
this one also touches like any place that could be found, so I combined
it.
===Patch begins here===
[PATCH] kernel: constify data and function pointer tables
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
drivers/char/apm-emulation.c |2 +-
drivers/char/drm/
Hi,
This touches so many different places that I did not feel like creating
a miniscule patch for each architecture. I hope that is ok.
===Patch begins===
[PATCH] procfs: constify function pointer tables
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
arch/alpha/kernel/s
On Jan 21 2008 22:16, Rusty Russell wrote:
>On Monday 21 January 2008 20:08:25 Denis Cheng wrote:
>> the original code use KOBJ_NAME_LEN for built-in module name length,
>> that's defined to 20 in linux/kobject.h, but this is not enough appearntly,
>> many module names are longer than this;
>> #d
On Jan 21 2008 05:48, Matthew Wilcox wrote:
>On Mon, Jan 21, 2008 at 02:13:52PM +0900, Tejun Heo wrote:
>> In a nutshell, printk_header() lets you do the following atomically
>> (against other messages).
>>
>> code:
>> printk(KERN_INFO "ata1.00: ", "line0\nline1\nline2\n");
>>
>> output:
>>
On Jan 22 2008 22:04, Manuel Reimer wrote:
>
> ... that may be possible...
>
> I have all PCI slots filled with cards, two big IDE hard drives and one DVD
> RAM
> writer. I already disconnected the DVD drive, as this was nearly unusable with
> all those IDE errors. The power supply is (AFAIR) a 2
On Jan 23 2008 08:51, Tejun Heo wrote:
>
>What do you think about the second suggestion then?
>
>ata1.00: line0
>ata1.00 line1
>ata1.00 line2
>
>It allows you to grab for the header && has indication for message
>boundaries.
Then again, why not "[ata1.00] line0", then it matches what sd_mod doe
On Jan 23 2008 12:18, Bryan Wu wrote:
>> [PATCH] procfs: constify function pointer tables
>> ---
>> arch/alpha/kernel/setup.c |2 +-
>> arch/blackfin/kernel/setup.c |2 +-
>> [...]
>> diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c
>> index bd5e68c..823f18e 100644
On Jan 23 2008 18:41, Bryan Wu wrote:
>Oh, this patch does not touch all, following is the missing list:
>---
[...]
>arch/ia64/hp/common/sba_iommu.c:static struct seq_operations ioc_seq_ops = {
>arch/ia64/kernel/perfmon.c:struct seq_operations pfm_seq_ops = {
>arch/ia64/kernel/setup.c:struct seq_o
On Jan 21 2008 19:49, Thomas, Sujith wrote:
>>>
>>> +MODULE_AUTHOR("Thomas Sujith");
>>> +MODULE_AUTHOR("Zhang Rui");
>>
>> I've never seen a driver with two MODULE_AUTHOR statements before.
>> Does this actually work? What does modinfo -F author say for your module?
>
>There is nothing wrong i
On Jan 23 2008 10:29, Matt Helsley wrote:
>
>For executables on the stackable MVFS filesystem the current procfs
>methods for implementing a task's exe symlink do not point to the
>correct file and applications relying on the symlink fail (see the
>java example below).
This reminds me of unoionfs
On Jan 19 2008 07:48, Andi Kleen wrote:
>Subject: [PATCH] [2/8] GBPAGES: Add feature macros for the gbpages cpuid bit
Is there already a flag for /proc/cpuinfo or could you add one?
>Index: linux/include/asm-x86/cpufeature.h
>===
>-
On Jan 24 2008 15:27, Mathieu Desnoyers wrote:
>such as:
>text_poke(addr, INIT_ARRAY(unsigned char, 0xf0, len), len);
text_poke(addr, (unsigned char[]){[0 ... len-1] = val});
Well ugliness is debatable, but at least:
>+#define INIT_ARRAY(type, val, len) ((type [len]) { [0 ... (len)-1] = (val) }
On Jan 24 2008 15:54, Mathieu Desnoyers wrote:
>
>Add initialization of an array, which needs brackets that would pollute kernel
>code, to kernel.h. It is used to declare arguments passed as function
>parameters
>such as:
>text_poke(addr, INIT_ARRAY(unsigned char, 0xf0, len), len);
>
>Changelog :
On Jan 24 2008 22:27, Sam Ravnborg wrote:
>> > > Trying to do a 32bit build on a 64bit machine.
>> > > I did..
>> > > make ARCH=i386 oldconfig
>> > > make ARCH=i386 arch/x86/
>> >
>> > Walking through my mailbox I found this one.
>> > I did not get similar reports and I cannot reproduc
On Oct 2 2007 12:56, Giuliano Gagliardi wrote:
>
>I have a server that has to switch to different user ids, but because it does
>other complex things, I would rather not have it run as root. I only need the
>server to be able to switch to certain pre-defined user ids.
All you need is CAP_SETUID
On Oct 2 2007 13:33, Giuliano Gagliardi wrote:
>Date: Tue, 2 Oct 2007 13:33:05 +0200
>From: Giuliano Gagliardi <[EMAIL PROTECTED]>
>To: Jan Engelhardt <[EMAIL PROTECTED]>
>Subject: Re: One process with multiple user ids.
>
>On Tuesday 02 October 2007, Jan Engelhardt
On Oct 2 2007 13:39, Giuliano Gagliardi wrote:
>>
>> You could write up a LSM that restricts UID changing.
>
>Would you not consider it more useful to let one process have multiple user
>ids? I do not see why they can have multiple group ids, but only (and
>exactly) three user ids.
It would rai
Lift the FS menu a bit by moving filesystem-specific
parts into their own menu.
This also moves minix and romfs into the "misc fs" menu,
as per Randy Dunlap's suggestion [http://lkml.org/lkml/2007/9/25/344]
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
f
On Oct 2 2007 08:41, Joe Perches wrote:
>On Tue, 2007-10-02 at 07:18 +0200, Ingo Molnar wrote:
>> +#define KERN_CONT ""
>
>This doesn't work with printk(char** array[index]) continuations
>or with strings with embedded KERN_ prefixes.
Huh?
...Ah. Yeah, pasting a string literal with a va
On Oct 2 2007 09:03, Joe Perches wrote:
>On Tue, 2007-10-02 at 17:45 +0200, Jan Engelhardt wrote:
>> always use printk("%s", var)
>
>You have to use indirect arguments to log something?
No, you do not have to.
>Don't you think that's a stupid rule?
Not at
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
fs/pipe.c | 49 -
1 file changed, 36 insertions(+), 13 deletions(-)
Index: linux-2.6.23/fs/pipe.c
===
--- linux-2.6.23.or
[PATCH]: Fill the size of FIFOs
Instead of reporting 0 in size when stating() a pipe, we give the number of
queued bytes. This might avoid using ioctl(FIONREAD) to get this information.
References: http://lkml.org/lkml/2007/4/2/138
Cc: Eric Dumazet <[EMAIL PROTECTED]>
Signed-off-b
Add %S_IWUGO bit for files on ISO-9660 filesystems without RockRidge
extensions. This allows one to modify the files right after copying,
without having to do an extra recursive chmod if `cp -p` or
`rsync -p` is used.
References: http://lkml.org/lkml/2007/4/1/164
Signed-off-by: Jan Engelhardt
Hi,
I am using 2.6.23-rc9 with pata_sis. `modprobe -r sd_mod`, which I ran
from initramfs, caused all my disks to spindown - sd even told me so.
I recall there has been talk a while back about whether to spin down
disks on shutdown or not, but I do not think it touched the removal of
sd_mod,
On Oct 2 2007 23:49, Jimmy wrote:
>
> Anyway, I've been trying to figure out what purpose the gpl-only code serves.
> What good comes out of disabling people from probing modules that do not have
> a
> gpl-compatible license?
find /lib/modules/`uname -r` -iname '*.ko' | wc -l:
2021
Pro
On Oct 3 2007 14:33, Frans Pop wrote:
>
>I saw top occasionally displaying % CPU usage for a process. The
>first few times it was amarokapp, this last time it was kontact.
>Both applications were basically idle.
Yes this certainly sounds like KDE. Did you try with Gnome,
or perhaps a simple `
On Oct 3 2007 09:09, Linus Torvalds wrote:
>On Wed, 3 Oct 2007, Alan Cox wrote:
>>
>> > and btw, there is no question what-so-ever about whether your compiler
>> > might be doing a legal optimization - the compiler really is wrong, and is
>>
>> Pedant: valid. Almost all optimizations are legal,
On Oct 4 2007 11:44, Pavel Machek wrote:
>diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
>index 7f1730f..1595a45 100644
>--- a/Documentation/CodingStyle
>+++ b/Documentation/CodingStyle
>@@ -71,6 +71,15 @@ used for indentation, and the above exam
>
> Get a decent editor and do
Hi,
I'd like to register a blkdev region, much like
blk_register_region(MKDEV(major, first_minor), number_minors,
xmodule, xprobe, xlock, xdata);
number_minors is known, but how do I decide what first_minor to use?
Module owns the full major number, so I tho
15 partitions (at least for sd_mod devices) are too few.
So I tried the following: after scanning the disk (sda), when we know
the number of partitions P on a disk, create a new block device
/dev/gd0 that is a copy of sda (in terms of disk->queue, etc.). This
is done using alloc_disk(P).
However
It is already possible to deactivate the vc bell on a per-tty basis,
by using echo -en "\e[11;0]", but this is reset on reset(1).
This adds a sysfs parameter to globally control the vc bell, as well
as sysfs parameters for default pitch and duration.
Signed-off-by: Jan Engelhar
On Oct 4 2007 20:46, Matthew Wilcox wrote:
>On Tue, Oct 02, 2007 at 08:00:26PM +0200, Jan Engelhardt wrote:
>> Add %S_IWUGO bit for files on ISO-9660 filesystems without RockRidge
>
>Looks to me like you've added S_IWUSR, not S_IWUGO.
Yes, S_IWUSR it should be, and is. When
On Oct 5 2007 13:27, Timur Tabi wrote:
>
> What's the difference between __LITTLE_ENDIAN and __LITTLE_ENDIAN_BITFIELD?
> Can
> someone give me an example when __BIG_ENDIAN and __LITTLE_ENDIAN_BITFIELD
> would
> both be defined simultaneously?
standard x86:
---LSB-- ---2SB-- ---3SB-- ---MSB-- [b
t, FreeBSD to some
extent, so I think Linux should too.
Inspired by cko (http://freshmeat.net/p/cko/), but independently
written, later contributed forth and back.
Already posted at: http://lkml.org/lkml/2007/4/1/162
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
drivers/cha
On Oct 5 2007 15:19, Lennart Sorensen wrote:
>On Fri, Oct 05, 2007 at 09:13:40PM +0200, Jan Engelhardt wrote:
>> +config VT_PRINTK_COLOR
>> +hex "Colored kernel message output"
>> +range 0x00 0xFF
>> +depends on VT_CONSOLE
>> +default 0x1
On Oct 5 2007 15:24, Lennart Sorensen wrote:
>On Fri, Oct 05, 2007 at 09:21:57PM +0200, Jan Engelhardt wrote:
>> Indeed it should be 0x07, should it go in.
>> Otherwise the openbsd camp might start another flamewar.
>>
>> (On a personal note, would 0x1F work better
On Oct 5 2007 14:35, Timur Tabi wrote:
>>
>> standard x86:
>> ---LSB-- ---2SB-- ---3SB-- ---MSB-- [bytes] LITTLE_ENDIAN
>> M765432L M765432L M765432L M765432L [bits] ?_BITFIELD
>>
>> (Not sure what bitfield type, but I'd guess BIG_ENDIAN_BITFIELD)
>
> Are you sure? I would think that all machi
On Oct 5 2007 15:43, Lennart Sorensen wrote:
>On Fri, Oct 05, 2007 at 09:32:11PM +0200, Jan Engelhardt wrote:
>> Ah you seem to be a proponent of http://www.blackgoogle.com/
>> then :-) Unfortunately, it seems like Xft uses Grayscale AA
>> (http://antigrain.com/resear
On Oct 5 2007 15:11, H. Peter Anvin wrote:
> Jan Engelhardt wrote:
>> 15 partitions (at least for sd_mod devices) are too few.
>
> Now when we have 20-bit minors, can't we simply recycle some of the
> higher bits for additional partitions, across the board? 63
> pa
On Oct 6 2007 01:22, Krzysztof Halasa wrote:
>Jan Engelhardt <[EMAIL PROTECTED]> writes:
>
>> +The value you need to enter here is the ASCII color value
>
>ASCII color value? ANSI perhaps?
ANSI:
\e[31m R--
\e[32m G--
\e[33m RG- (yellow)
\e[34m --B
\e[35m R-B (magen
On Oct 6 2007 02:10, Krzysztof Halasa wrote:
>Jan Engelhardt <[EMAIL PROTECTED]> writes:
>
>>>I wonder how accurate is it.
>>
>> Since I do not use 512-glyph fonts, I do not know.
>
>Actually I meant "how accurate my remarks are" :-)
>
>Not
On Oct 6 2007 02:23, Jan Engelhardt wrote:
>>
>>Not convinced WRT ASCII color codes, though. ASCII doesn't contain
>>codes for changing colors. Perhaps some specific "extended ASCII"?
>
>Start up QBasic, issue
> COLOR 1
>=> blue.
>
&g
On Oct 6 2007 10:55, Alan Cox wrote:
>> >
>> > It is already possible to deactivate the vc bell on a per-tty basis,
>> > by using echo -en "\e[11;0]", but this is reset on reset(1).
>> >
>> > This adds a sysfs parameter to globally control the vc bell, as well
>> > as sysfs parameters for defaul
On Oct 5 2007 17:00, Andrew Morton wrote:
>>
>> It is already possible to deactivate the vc bell on a per-tty basis,
>> by using echo -en "\e[11;0]", but this is reset on reset(1).
>>
>> This adds a sysfs parameter to globally control the vc bell, as well
>> as sysfs parameters for default pitch
one that vt.c used for all the
past years anyway, so apart from the config option, nothing changes
for the conservative user.
References: http://lkml.org/lkml/2007/4/1/162
http://lkml.org/lkml/2007/10/5/199
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
drivers/char/Kconfig
Colored kernel message output (2/2)
By popular request, this patch adds per-loglevel coloring.
The user may set values using vt.printk_color= or by modifying
the sysfs file in the running system.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/early_printk.c
On Oct 6 2007 15:53, Bill Davidsen wrote:
> Jan Engelhardt wrote:
>> Colored kernel message output
>>
>> Let's work more on Linux's cuteness! [http://lkml.org/lkml/2007/10/4/431]
>> The following patch makes it possible to give kernel messages a
>> sel
-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
drivers/char/Kconfig | 42 ++
drivers/char/vt.c| 23 +++
2 files changed, 65 insertions(+)
Index: linux-2.6.23/drivers/char/K
Colored kernel message output (2/2)
By popular request, this patch adds per-loglevel coloring.
The user may set values using vt.printk_color= or by modifying
the sysfs file in the running system.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/early_printk.c
On Oct 3 2007 10:55, Bodo Eggert wrote:
>
>> [PATCH]: Fill the size of FIFOs
>>
>> Instead of reporting 0 in size when stating() a pipe
>
>FIFO
Yes
-
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
On Oct 5 2007 21:49, Hugh Dickins wrote:
>> > > $ zcat /proc/config.gz | grep TMPFS
>> > > # CONFIG_TMPFS is not set
>> > > $ grep tmpfs /proc/filesystems
>> > > nodev tmpfs
>> >
>> > tmpfs (mm/shmem.c) is used by the kernel to support shared memory
>> > of various kinds even when CONFIG_TMPFS
On Oct 6 2007 23:03, Oleg Verych wrote:
>>
>> (btw., i corrected the subject line to remove the 'NAK'. Why do you
>> think you can 'NAK' a patch in this field?)
>
>I added comment (like this), so anyone can skip reading body, if headers
>are "Oleg Verych && NAK". In case if `NAK' have a magic me
On Oct 6 2007 23:25, Oleg Verych wrote:
>> ---
>> arch/x86_64/kernel/early_printk.c | 11 +++
>> drivers/char/Kconfig |4 +++-
>> drivers/char/vt.c | 32
>> drivers/net/netconsole.c |3 ++-
>> drivers/seria
On Oct 7 2007 00:28, Oleg Verych wrote:
>
>I thought, i was talking about *write() functions, that got one
>additional unrelated, non config removable API change in face of
>`unsigned int loglevel'.
Documentation/stable_api_nonsense.txt ;-)
>Idea. Extend those macro defines before format string
On Oct 6 2007 20:50, Bill Davidsen wrote:
>>
>>> I start my root xterm in white on blue for identification, so color coding
>>> sounds like a great idea to me.
>>
>> This has nothing to do with xterms, this is "VGA color console" only.
>> xterm config is in /usr/share/X11/app-defaults/XTerm-colo
On Oct 7 2007 16:12, Alan Cox wrote:
>
>- We run on a lot more than VGA PC consoles
>- We have serial consoles (which may or may not be VT132/ANSI compliant)
Yes, and the serial driver does not usually pass on vc->vc_color to the real
hardware. If it did, it would have to transform it back into a
On Oct 7 2007 13:10, Oleg Verych wrote:
>This `scrollback' is usual late boot / console one. If fact useful,
>until first tty switch or if `screen` cannot be used. But for some
>reason if scrolling region (DECSTBM) is less than whole screen, nothing
>works.
Actually, scrolling begins to work onc
On Oct 7 2007 18:38, Ingo Molnar wrote:
>
>minor fix: i had to use the slightly modified patch below instead of the
>one you posted, so that the second patch applies fine.
What is it that you changed? The printk patches are right at the front,
so there should not be any fuzz or offsets (might va
On Oct 7 2007 18:44, Ingo Molnar wrote:
>> This patch makes it possible to give kernel messages a selectable
>> color. It can be chosen at compile time, overridden at boot time, and
>> changed at run time.
>
>here's some (good) text footprint data:
>
>with the feature disabled (which is the defa
On Oct 7 2007 18:59, Ingo Molnar wrote:
>> > vmlinux:
>> > textdata bss dec hex filename
>> > 7732358 1157269 401408 9291035 8dc51b vmlinux.before
>> > 7732374 1157269 401408 9291051 8dc52b vmlinux.after
>> >
>> >16 bytes, or 0.0002% of the total text size. So there's in
On Oct 7 2007 20:47, Rene Herman wrote:
>
>> > Coloring isn't useful. If it was, it would be implemented ~16 years
>> > ago.
>>
>> Congratulations, this is the most stupid argument i've ever read on lkml.
>
> "Ay. World is finished. Everyone can go home and watch Friends reruns now."
>
> But well
On Oct 7 2007 21:13, Willy Tarreau wrote:
>There are two distinct populations :
> - those [...]
>who would never have imagined that pressing Escape
>during the boot of windows 3.1/95 provided them with the full text
>messages.
This is news to me. DOS always showed messages, and under
On Oct 7 2007 21:27, Rene Herman wrote:
>
> I saw you remark on FB console in a reply to Alan just now and I
> quite agree with you. The (current) FB console is slow and I'll add
> "dumb" myself. When you have a 1280x1024 screen available, you get
> to do cool things like put up nice little window
On Oct 7 2007 22:00, Rene Herman wrote:
> On 10/07/2007 09:56 PM, Jan Engelhardt wrote:
>
>> Some is good, as long as it is not excessive. While I could imagine that
>> Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this
>> is not what serious pe
On Oct 7 2007 22:50, Oleg Verych wrote:
>
>In fact mc config (ini) section is a better way.
Yes, for the default colors. But /usr/share/mc/syntax/ specifies
more of them.
>I use default blue (which is very annoying)
If blue were annoying, it would not be the default Windows background
(since Wi
On Oct 8 2007 00:18, Oleg Verych wrote:
>
>Kind of funny thing with it. One for shell in `mcedit` is much nicer, but
>`emacs` is more powerful as editor(R). But both have highlighting
>problems with non trivial scripts (quoiting, data here, etc). I don't
>know if it will ever be fixed :).
No, it
On Oct 8 2007 01:02, Oleg Verych wrote:
>
>If you are not going to see OOPes of new kernels running old distros, ask
>any perl hacker (as they lovely mentioned in lkml) to hack for you
>something like:
>
>sed -u -e '
>/^<1/s_^_'$COLOR1'_
>/^<2/s_^_'$COLOR2'_
>/^<3/s_^_'$COLOR3'_
>/^<4/s_^_'$COLOR4
On Oct 7 2007 17:23, Alan Cox wrote:
>
>>>- If you want to do "pretty" boot up you do it in X or frame buffer
>>>(which is going to get easier and easier with the X shift to kernel side
>>>video support)
>>
>> fb is slow. Feels like a 9600bps serial line.
>
>So fix your fb. There is enough inform
On Oct 8 2007 19:37, Sam Ravnborg wrote:
>snip...
>
>Or maybe we need something much less formal that explain the purpose of the
>four tags we use:
At least formal try:
>Signed-of-by:
* Used by original submitter(s).
* Also used by maintainers to track the patch's path
(ATM, does not imply "I
On Oct 9 2007 07:12, Antonino A. Daplas wrote:
>>
>> References: http://lkml.org/lkml/2007/4/1/162
>> http://lkml.org/lkml/2007/10/5/199
>
>This is quite a long thread :-)
It was a patch series after all. But as Greg puts it, be persistent.
>> +config VT_PRINTK_COLOR
>> +hex "Colored k
On Oct 9 2007 09:26, Vasily Averin wrote:
>
>On one of our servers timer interrupts (i.e irq0) are stops working. As result
>any kernel timers do not triggers and tasks waiting some signals from timers
>hangs forever.
What kernel.. and tried CONFIG_NO_HZ=n?
-
To unsubscribe from this list: send
On Oct 8 2007 14:55, James Bowes wrote:
> 20: Check that it all passes `make headers_check'.
>
> 21: Has been checked with injection of at least slab and page-allocation
>-fauilures. See Documentation/fault-injection/.
>+failures. See Documentation/fault-injection/.
It was a fault inje
On Oct 10 2007 14:36, Alexey Dobriyan wrote:
>> >> --- linux-2.6.23/include/linux/mm.h.vanilla
>> >> +++ linux-2.6.23/include/linux/mm.h
>> >
>> >> +struct super_block;
>> >> extern void drop_pagecache_sb(struct super_block *);
>> >> void drop_pagecache(void);
>> >> void drop_slab(void);
>> >>
On Oct 11 2007 00:13, Russ Dill wrote:
>
>/* only text is profiled */
>> prof_len = (unsigned *) &_etext - (unsigned *) &_stext;
Uh, that's some evil pointer arithmetic :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Oct 11 2007 08:01, Rick Niles wrote:
>
> I've been trying to make the driver work with
> Fedora 7 and the 2.6.22 kernel, but the rtc_register() and other RTC functions
> seems to have been removed.
grep -r rtc_device_register drivers/rtc/
Does that help?
> I see they've been replaced by the
On Oct 11 2007 08:51, Rick Niles wrote:
>
> Maybe I'm way off here, but that seems to be the function to register a RTC
> hardware chip with the kernel. I want to use a real-time clock interrupt to
> wake up my driver and service the GPS correlator, about every 500ms. Please
> let me know if I'm
On Oct 11 2007 15:53, mahamuni ashish wrote:
>--
>[EMAIL PROTECTED] device_driver]# make
>
>gcc -O2 -DMODULE -D__KERNEL__ -isystem
>/usr/src/kernels/2.6.18-1.2798.fc6-i686/include -c
>-o ins.o ins.c
Time to read Documentation/kbuild/.
-
To unsubscribe from this list:
On Oct 11 2007 11:54, Randy Dunlap wrote:
>On Thu, 11 Oct 2007 11:33:35 -0700 Agarwal, Lomesh wrote:
>
>> Below is the patch for TPM driver.
>> Comments/suggestions?
>
>Observe/use kernel coding style.
>Run the patch thru scripts/checkpatch.pl and check its suggestions.
>Use "diffstat -p1 -w70" an
On Dec 20 2007 23:05, Ilpo Järvinen wrote:
>>
>> Given the fact that I've had this problem for so long, over a variety
>> of networking hardware vendors and colo-facilities, this really sounds
>> good to me. It will be challenging for me to justify a kernel core
>> dump, but a simple patch to du
On Dec 20 2007 18:15, Andrew Morton wrote:
>
>No-period is a kernel idiom, produces perfectly readable output, I have
>never ever heard of anyone expressing the least concern over a lack of dots
>at the end of their printks and 91% of kernel code agrees.
Let's check out some real-world messages,
On Dec 21 2007 17:56, Herbert Xu wrote:
>>
>> I do not believe "opinions" are relevant here. Relevant would be cites
>> from respected style guides (Fowlers, Oxford Guide To Style et al.) to
>> show they do not need a full stop.
>>
>> I've not found one, but I am open to references.
>
>Well fro
On Dec 21 2007 19:41, Herbert Xu wrote:
>On Fri, Dec 21, 2007 at 11:10:38AM +0100, Jan Engelhardt wrote:
>>
>> >[XFS] Initialise current offset in xfs_file_readdir correctly
>> >
>> >The reason is that it lacks a subject.
>>
>> "current of
On Dec 21 2007 12:08, James Courtier-Dutton wrote:
> That being said, I don't think sse and mmx are available in kernel
> space, so I would have suggested doing all the grunt work in
> userspace would be better for this persons application so that he
> could use sse and mmx etc.
>
They are availa
On Dec 21 2007 16:30, Al Boldi wrote:
>
>The current USB Kconfig menu is rather cluttered and unorganized.
>
>Propose new layout as follows:
>
Yes, this has been done before in a lot of places, and attempts to
clean up more menus is always welcome.
Try to use 'menuconfig' objects so people can d
On Dec 21 2007 15:31, Eric Paris wrote:
>On Thu, 2007-12-20 at 00:29 +0100, Jan Engelhardt wrote:
>> On Dec 19 2007 16:59, Eric Paris wrote:
>> >
>> >+config SECURITY_DEFAULT_MMAP_MIN_ADDR
>> >+int "Low address space to protect from user alloc
On Dec 21 2007 14:35, Greg KH wrote:
>> >> >I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is
>> >> >base 10 as well
>> >>
>> >> sysfs is autobase, i.e. echo "0xb000" >/sys/foo will Do The Right Thing.
>> >
>> >yes but if you cat /proc/sys/vm/mmap_min_addr, it returns in base
On Dec 21 2007 22:16, Willy Tarreau wrote:
>Hi Jan,
>
>> >> >+config SECURITY_DEFAULT_MMAP_MIN_ADDR
>> >> >+int "Low address space to protect from user allocation"
>> >>
>> >> Hm, should not this be 'hex'?
>> >
>> >I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is
>> >b
On Dec 23 2007 14:49, Al Boldi wrote:
>--- 23.a/drivers/usb/Kconfig
>+++ 23.b/drivers/usb/Kconfig
>@@ -2,8 +2,8 @@
> # USB device configuration
> #
>
>-menuconfig USB_SUPPORT
>- bool "USB support"
>+config USB_SUPPORT
>+ bool
> depends on HAS_IOMEM
> default y
> ---hel
On Dec 23 2007 16:15, Al Boldi wrote:
>> >-menuconfig USB_SUPPORT
>> >- bool "USB support"
>> >+config USB_SUPPORT
>> >+ bool
>> >depends on HAS_IOMEM
>> >default y
>> >---help---
>>
>> With this patch, is USB_SUPPORT still needed? It is not visible (anymore),
>> always is y and no
On Dec 23 2007 16:25, Jan Engelhardt wrote:
>On Dec 23 2007 16:15, Al Boldi wrote:
>>> >-menuconfig USB_SUPPORT
>>> >- bool "USB support"
>>> >+config USB_SUPPORT
>>> >+ bool
>>> > depends on HAS_IOMEM
>>> >
On Dec 26 2007 17:01, H. Peter Anvin wrote:
>> > @@ -215,7 +215,9 @@ asmlinkage int sys_vm86old(struct pt_reg
>> > ret = -EFAULT;
>> > if (tmp)
>> >goto out;
>> > - memset(&info.vm86plus, 0, (int)&info.regs32 - (int)&info.vm86plus);
>> > + memset(&info.vm86plus, 0,
>> > +
On Dec 27 2007 11:11, Jan Evert van Grootheest wrote:
>>
>> The subject of the individual patches are in the email thread that is
>> attached to this announcement, so it should be quite simple to get this
>> information by just looking in your mail reader :)
>>
>> Also, it would be hard to do this
On Dec 28 2007 11:09, Jiri Slaby wrote:
>
>+struct mxser_cardinfo {
>+ unsigned int nports;
>+ char *name;
>+ unsigned int flags;
>+};
const char *name. Maybe name could also be put at the front
to get closer struct packing on 64-bit?
>
>+static int mxvar_baud_table[] = {
>+
On Dec 28 2007 14:01, [EMAIL PROTECTED] wrote:
>+
>+ * The initial minor number is 128 to prevent clashes with ttyS:
>+ * mknod /dev/ttyMAX0 c 4 128
>+ */
[4:128] is taken by ttyS64. Please look into Documentation/devices.txt.
>+struct max3100_port_s {
>+ struct uart_port port;
>+ stru
[Adding jcm to Cc]
On Dec 28 2007 16:08, [EMAIL PROTECTED] wrote:
>
>i have the same issue, but with 2.6.24-rc6 on a box with 512MB RAM
>
>System is openSUSE 10.3
>
>on "make modules_install" , depmod reproduceably dies with out of memory error
>when it is ~800MB VSZ and ~350MB RSS
>this happens
On Dec 28 2007 18:53, dean gaudet wrote:
>p.s. in retrospect i probably could have arranged it more like this:
>
> mount /dev/md1 $tmpmntpoint
> mount --bind $tmpmntpoint/var /var
> mount --bind $tmpmntpoint/home /home
> umount $tmpmntpoint
>
>except i can't easily specify that in fstab... and
On Dec 28 2007 22:02, dean gaudet wrote:
>
>i was trying to come up with a userland-only change in mount(8) which
>would behave like so:
>
># mount --subtree var /dev/md1 /var
> internally mount does:
> - mount /dev/md1 /tmpmnt
> - mount --bind /tmpmnt/var /var
> - umount /tmpmnt
>
># mount --
301 - 400 of 2192 matches
Mail list logo
