Re: [PATCH] net: Make skb_seq_read unmap the last fragment
From: Olaf Kirch <[EMAIL PROTECTED]> Date: Tue, 19 Jun 2007 09:56:24 +0200 > From: Olaf Kirch <[EMAIL PROTECTED]> > > Make skb_seq_read unmap the last fragment > > Having walked through the entire skbuff, skb_seq_read would leave the > last fragment mapped. As a consequence, the unwary caller would leak > kmaps, and proceed with preempt_count off by one. The only (kind of > non-intuitive) workaround is to use skb_seq_read_abort. > > This patch makes sure skb_seq_read always unmaps frag_data after having > cycled through the skb's paged part. > > Signed-off-by: [EMAIL PROTECTED] Thanks for finding and fixing this bug. Patch applied, thanks again Olaf. - 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH 2.6.21.5] ppp: fix osize too small errors when decoding mppe
From: Konstantin Sharlaimov <[EMAIL PROTECTED]> Date: Wed, 20 Jun 2007 22:37:18 +1100 > The mppe_decompress() function required a buffer that is 1 byte too small when > receiving a message of mru size. This fixes buffer allocation to prevent this > from occurring. > > Signed-off-by: Konstantin Sharlaimov <[EMAIL PROTECTED]> This looks better, I've reverted the original version of the fix and applied this new one. > --- linux-2.6.21.3/drivers/net/ppp_generic.c.orig 2007-06-20 > 09:14:13.0 > +1100 > +++ linux-2.6.21.3/drivers/net/ppp_generic.c 2007-06-20 09:18:06.0 > +1100 Please prevent your email client from corrupting patches like this by adding new lines. I've fixed up your patches by hand now twice, I'm not going to do it any more. Thanks. - 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 read the FAQ at http://www.tux.org/lkml/
Re: can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Fri, Jun 22, 2007 at 09:59:47AM -0400, Alan Stern wrote: > On Fri, 22 Jun 2007, Mattia Dongili wrote: > > > > Yes, the problem is not present after reverting this patch. > > > > Not for me, I had that patch already reverted. As I said there was a > > point when bisecting which the kernel came back to life instead of just > > hanging trying to suspend. > > I'll try to get a trace with that. May the usb_storage verbose debug > > help there? > > I've lost track of the start of this thread, so it would help to see a > dmesg log with CONFIG_USB_DEBUG turned on. CONFIG_USB_STORAGE_DEBUG > doesn't matter so much because the usb-storage suspend and resume > routines don't do a lot of work. Sorry, it was probably me who messed things up. It looks like it's not usb-storage who's preventing suspend here. I have this diff between a single user mode where I can suspend and a multiuser environment where suspend hangs, will go loading the missing modules one by one and get a better idea... Sorry for the noise. --- /root/lsmod-str.txt 2007-06-24 10:58:09.953207666 +0900 +++ /root/lsmod-str-nono.txt2007-06-24 14:21:33.354417422 +0900 @@ -1,10 +1,20 @@ +ac +acpi_cpufreq agpgart arc4 +auth_rpcgss backlight +battery blkcipher bluetooth +button cdrom cfg80211 +cpufreq_conservative +cpufreq_ondemand +cpufreq_powersave +cpufreq_stats +cpufreq_userspace dm_crypt dm_mirror dm_mod @@ -12,20 +22,39 @@ ecb ehci_hcd evdev +exportfs +fan firmware_class +freq_table fuse hci_usb i2c_i801 ide_cd +inet_diag intel_agp +iptable_filter +iptable_nat +ip_tables +ipt_MASQUERADE +ipv6 iwl3945 +l2cap +lockd loop mac80211 +nf_conntrack +nf_conntrack_ipv4 +nf_nat +nfnetlink +nfs +nfs_acl +nfsd pcmcia pcmcia_core psmouse r5u870 rc80211_simple +rfcomm rsrc_nonstatic rtc sky2 @@ -38,16 +67,22 @@ snd_timer sony_laptop soundcore +sunrpc +tcp_diag +thermal tifm_7xx1 tifm_core tpm tpm_bios tpm_infineon uhci_hcd -usb_storage usbcore +usb_storage v4l1_compat v4l2_common video_buf videodev +x_tables +xt_state +xt_tcpudp yenta_socket -- mattia :wq! - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
Grozdan Nikolov wrote: On Saturday 23 June 2007 21:18, you wrote: There's a lot in Linux that was true innnovation: Alan Cox's Networking Architecture. VFS Architecture (best one out there -- even better than M$'s) Scheduler Design. Jeff Thanks Jeff, so from reading all the responses here I can conclude that Linux innovates stuff by itself and not only gets it from other places. Is it also right to say that other kernels, be it BSD, Solaris, maybe AIX?, also benefit from the Linux innovations? Absolutely. Every operating system benefits from the cross pollination of ideas that happens on mailing lists, through white papers and at conferences. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - 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 read the FAQ at http://www.tux.org/lkml/
vm/fs meetup in september?
I'd just like to take the chance also to ask about a VM/FS meetup some time around kernel summit (maybe take a big of time during UKUUG or so). I was thinking about trying to arrange a proper mini summit thing, but it's a bit difficult and we could talk this year about doing it for subsequent years. If there is a bit of interest, we could probably find a small room somewhere this year on pretty short notice or do it as a BOF or something. I don't want to do it in the VM summit, because that kind of alienates the filesystem guys. What I want to talk about is anything and everything that the VM can do better to help the fs and vice versa. I'd like to stay away from memory management where not too applicable to the fs. A few things I'd like to talk about are: - the address space operations APIs, and their page based nature. I think it would be nice to generally move toward offset,length based ones as much as possible because it should give more efficiency and flexibility in the filesystem. - write_begin API if it is still an issue by that date. Hope not :) - truncate races - fsblock if it hasn't been shot down by then - how to make complex API changes without having to fix most things yourself. Anyway, if you will be in the area and are interested, let me know (off list) and we can work out time and place. Thanks, Nick - 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC] fsblock
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote: > fsblock is a rewrite of the "buffer layer" (ding dong the witch is > dead), which I have been working on, on and off and is now at the stage > where some of the basics are working-ish. This email is going to be > long... Long overdue. Thank you. -- wli - 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 read the FAQ at http://www.tux.org/lkml/
Re: JIT emulator needs
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
>>> c. open() flag to unlink a file before returning the fd
On Jun 19, 2007, at 11:08:24, William Lee Irwin III wrote:
>> You probably want a tmpfile(3) -like affair which never has a
>> pathname to begin with. It could be useful for security purposes
>> more generally.
On Fri, Jun 22, 2007 at 11:52:12PM -0400, Kyle Moffett wrote:
> maybe this: open("/some/dir", O_TMPFILE);
> and this? open("/some/dir", O_TMPFILE|O_DIRECTORY);
> The former would return a filehandle to a new anonymous file
> somewhere on whatever filesystem backs the specified path. The
> latter would do the same, except create an anonymous directory where
> you could use "openat()" or something. Presumably "lsof" and "/proc"
> should show either type of handle as referring to either "/some/
> filesystem/" or "/some/filesystem/ (anonymous temp file)" or something.
This is plausible (and I did indeed consider the file variant),
though it may require more infrastructure than for tmpfs only.
It may be worth clarifying that I have no concrete plans to work on
the JIT emulator issues myself. I'm only disseminating ideas I think
will pass review. I expect others to take up the issue(s) perhaps with
some inspiration from what I described. I may review some, but I have
a large review backlog as things now stand.
-- wli
-
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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] fbdev: uvesafb driver
> +static int uvesafb_blank(int blank, struct fb_info *info)
> +{
> + struct uvesafb_par *par = info->par;
> + struct uvesafb_ktask *task;
> + int err = 1;
> +
> + if (par->vbe_ib.capabilities & VBE_CAP_VGACOMPAT) {
> + int loop = 1;
> + u8 seq = 0, crtc17 = 0;
> +
> + if (blank == FB_BLANK_POWERDOWN) {
> + seq = 0x20;
> + crtc17 = 0x00;
> + err = 0;
> + } else {
> + seq = 0x00;
> + crtc17 = 0x80;
> + err = (blank == FB_BLANK_UNBLANK) ? 0 : -EINVAL;
> + }
> +
> + vga_wseq(NULL, 0x00, 0x01);
> + seq |= vga_rseq(NULL, 0x01) & ~0x20;
> + vga_wseq(NULL, 0x00, seq);
> +
> + crtc17 |= vga_rcrt(NULL, 0x17) & ~0x80;
> + while (loop--);
> + vga_wcrt(NULL, 0x17, crtc17);
> + vga_wseq(NULL, 0x00, 0x03);
> + } else {
> + task = uvesafb_prep();
> + if (!task)
> + return -ENOMEM;
> +
> + task->t.regs.eax = 0x4f10;
> + switch (blank) {
> + case FB_BLANK_UNBLANK:
> + task->t.regs.ebx = 0x0001;
> + break;
> + case FB_BLANK_NORMAL:
> + task->t.regs.ebx = 0x0101; /* standby */
> + break;
> + case FB_BLANK_POWERDOWN:
> + task->t.regs.ebx = 0x0401; /* powerdown */
> + break;
> + default:
> + goto out;
> + }
> + task->t.flags = 0;
> +
> + err = uvesafb_exec(task);
> + if (!err && (task->t.regs.eax & 0x) == 0x004f)
> + err = 0;
There is no effect to this assignment.
if (!err && ... )
err = 0;
> +out: uvesafb_free(task);
> + }
> + return err;
> +}
[...]
> +static int __devinit uvesafb_init(void)
> +{
> + int err;
> +
> +#ifndef MODULE
> + char *option = NULL;
> +
> + if (fb_get_options("uvesafb", &option))
> + return -ENODEV;
> + uvesafb_setup(option);
> +#endif
> + err = cn_add_callback(&uvesafb_cn_id, "uvesafb", uvesafb_cn_callback);
> + if (err)
> + goto err_out;
> +
> + err = platform_driver_register(&uvesafb_driver);
> +
> + if (!err) {
> + uvesafb_device = platform_device_alloc("uvesafb", 0);
> + if (uvesafb_device)
> + err = platform_device_add(uvesafb_device);
> + else
> + err = -ENOMEM;
> +
> + if (err) {
> + platform_device_put(uvesafb_device);
> + platform_driver_unregister(&uvesafb_driver);
Initialization failed. It should return from this function here.
Otherwise it will attempt to call driver_create_file() with unregistered
driver below.
And you forgot to put:
cn_del_callback(&uvesafb_cn_id);
> + }
> +
> + err = driver_create_file(&uvesafb_driver.driver,
> + &driver_attr_v86d);
> + if (err) {
> + printk(KERN_WARNING "uvesafb: failed to register "
> + "attributes\n");
> + err = 0;
> + }
> + }
> + return err;
> +
> +err_out:
> + if (nls && nls->sk_socket)
> + sock_release(nls->sk_socket);
I can't find any uses of nls in this driver.
> + return err;
> +}
-
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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC] fsblock
On Sat, Jun 23, 2007 at 11:07:54PM -0400, Jeff Garzik wrote: > Nick Piggin wrote: > >- No deadlocks (hopefully). The buffer layer is technically deadlocky by > > design, because it can require memory allocations at page writeout-time. > > It also has one path that cannot tolerate memory allocation failures. > > No such problems for fsblock, which keeps fsblock metadata around for as > > long as a page is dirty (this still has problems vs get_user_pages, but > > that's going to require an audit of all get_user_pages sites. Phew). > > > >- In line with the above item, filesystem block allocation is performed > > before a page is dirtied. In the buffer layer, mmap writes can dirty a > > page with no backing blocks which is a problem if the filesystem is > > ENOSPC (patches exist for buffer.c for this). > > This raises an eyebrow... The handling of ENOSPC prior to mmap write is > more an ABI behavior, so I don't see how this can be fixed with internal > changes, yet without changing behavior currently exported to userland > (and thus affecting code based on such assumptions). I believe people are happy to have it SIGBUS (which is how the VM is already set up with page_mkwrite, and what fsblock does). > >- An inode's metadata must be tracked per-inode in order for fsync to > > work correctly. buffer contains helpers to do this for basic > > filesystems, but any block can be only the metadata for a single inode. > > This is not really correct for things like inode descriptor blocks. > > fsblock can track multiple inodes per block. (This is non trivial, > > and it may be overkill so it could be reverted to a simpler scheme > > like buffer). > > hrm; no specific comment but this seems like an idea/area that needs to > be fleshed out more, by converting some of the more advanced filesystems. Yep. It's conceptually fairly simple though, and it might be easier than having filesystems implement their own complex syncing that finds and syncs everything themselves. > >- Large block support. I can mount and run an 8K block size minix3 fs on > > my 4K page system and it didn't require anything special in the fs. We > > can go up to about 32MB blocks now, and gigabyte+ blocks would only > > require one more bit in the fsblock flags. fsblock_superpage blocks > > are > PAGE_CACHE_SIZE, midpage ==, and subpage <. > > definitely useful, especially if I rewrite my ibu filesystem for 2.6.x, > like I've been planning. Yeah, it wasn't the primary motivation for the rewrite, but it would be negligent to not even consider large blocks in such a rewrite, I think. > >So. Comments? Is this something we want? If yes, then how would we > >transition from buffer.c to fsblock.c? > > Your work is definitely interesting, but I think it will be even more > interesting once ext2 (w/ dir in pagecache) and ext3 (journalling) are > converted. Well minix has dir in pagecache ;) But you're completely right: ext2 will be the next step and then ext3 and things like XFS and NTFS will be the real test. I think I could eventually get ext2 done (one of the biggest headaches is simply just converting ->b_data accesses), however unlikely a journalling one. > My gut feeling is that there are several problem areas you haven't hit > yet, with the new code. I would agree with your gut :) > Also, once things are converted, the question of transitioning from > buffer.c will undoubtedly answer itself. That's the way several of us > handle transitions: finish all the work, then look with fresh eyes and > conceive a path from the current code to your enhanced code. Yeah that would be nice. It's very difficult because of so much filesystem code. I'd say it would be feasible to step buffer.c into fsblock.c, however if we were to track all (or even the common) filesystems along with that it would introduce a huge number of kind-of-redundant changes that I don't think all fs maintainers would have time to write (and as I said, I can't do it myself). Anyway, let's cross that bridge if and when we come to it. For now, the big thing that needs to be done is convert a "big" fs and see if the results tell us that it's workable. Thanks for the comments Jeff. - 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 read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On 6/24/07, Trent Piepho <[EMAIL PROTECTED]> wrote: On Sat, 23 Jun 2007, Satyam Sharma wrote: > On 6/23/07, Trent Piepho <[EMAIL PROTECTED]> wrote: > > [...] > > Now all the usb drivers will gain USB as a dependency directly and can't be > > set to something higher than USB. > > Ok, so we add this as solution 2.(c) to the reply I just sent to Jan :-) > > But I still prefer 2.(b) -- making the config scripts intelligent so that if a > given "menuconfig FOO depends on BAR", then all the "config BAZ"s > inside this menuconfig also automatically "depend on" BAR too. Of course, there currently is no "inside" a menuconfig. You would have to do something like make everything inside an "if FOO / endif" gain not just a dependency on FOO, but also gain a dependency on all of FOO's dependencies. Yes, making the config scripts do what you describe there automagically is exactly what I meant there. > This is simpler in the long run because it requires least amount > (actually none) of redundant typing and would continue to work in > the future if/when the: > [...] > configmenu FOO > ... > endconfigmenu # FOO > > kind of idiom ... Like that I suggested here? http://article.gmane.org/gmane.linux.kernel/524823 Basically, make menuconfig work like menu does, except the menu itself can be turned on and off. Instead of having menuconfig work like a config, but with some kind of "menu" hint. It seems like the former is more in line with what menuconfig is actually used for. Again, we're in complete agreement here (also like what Jan mentioned elsewhere on this thread). But then there's often too much "suggestions" on Kconfig/Kbuild matters on lkml, but too little code (wonder if that was what got Roman irritated yesterday). This may be because stuff in scripts/ doesn't quite get the kind of eyeballs kernel/ or fs/ or even drivers/ gets, but I guess the only way to get Roman around to our view would be start submitting patches for the solutions we're all fond of "suggesting" :-) Satyam - 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC] fsblock
Nick Piggin wrote: - No deadlocks (hopefully). The buffer layer is technically deadlocky by design, because it can require memory allocations at page writeout-time. It also has one path that cannot tolerate memory allocation failures. No such problems for fsblock, which keeps fsblock metadata around for as long as a page is dirty (this still has problems vs get_user_pages, but that's going to require an audit of all get_user_pages sites. Phew). - In line with the above item, filesystem block allocation is performed before a page is dirtied. In the buffer layer, mmap writes can dirty a page with no backing blocks which is a problem if the filesystem is ENOSPC (patches exist for buffer.c for this). This raises an eyebrow... The handling of ENOSPC prior to mmap write is more an ABI behavior, so I don't see how this can be fixed with internal changes, yet without changing behavior currently exported to userland (and thus affecting code based on such assumptions). - An inode's metadata must be tracked per-inode in order for fsync to work correctly. buffer contains helpers to do this for basic filesystems, but any block can be only the metadata for a single inode. This is not really correct for things like inode descriptor blocks. fsblock can track multiple inodes per block. (This is non trivial, and it may be overkill so it could be reverted to a simpler scheme like buffer). hrm; no specific comment but this seems like an idea/area that needs to be fleshed out more, by converting some of the more advanced filesystems. - Large block support. I can mount and run an 8K block size minix3 fs on my 4K page system and it didn't require anything special in the fs. We can go up to about 32MB blocks now, and gigabyte+ blocks would only require one more bit in the fsblock flags. fsblock_superpage blocks are > PAGE_CACHE_SIZE, midpage ==, and subpage <. definitely useful, especially if I rewrite my ibu filesystem for 2.6.x, like I've been planning. So. Comments? Is this something we want? If yes, then how would we transition from buffer.c to fsblock.c? Your work is definitely interesting, but I think it will be even more interesting once ext2 (w/ dir in pagecache) and ext3 (journalling) are converted. My gut feeling is that there are several problem areas you haven't hit yet, with the new code. Also, once things are converted, the question of transitioning from buffer.c will undoubtedly answer itself. That's the way several of us handle transitions: finish all the work, then look with fresh eyes and conceive a path from the current code to your enhanced code. Jeff - 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC] fsblock
Just clarify a few things. Don't you hate rereading a long work you wrote? (oh, you're supposed to do that *before* you press send?). On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote: > > I'm announcing "fsblock" now because it is quite intrusive and so I'd > like to get some thoughts about significantly changing this core part > of the kernel. > > fsblock is a rewrite of the "buffer layer" (ding dong the witch is > dead), which I have been working on, on and off and is now at the stage > where some of the basics are working-ish. This email is going to be > long... > > Firstly, what is the buffer layer? The buffer layer isn't really a > buffer layer as in the buffer cache of unix: the block device cache > is unified with the pagecache (in terms of the pagecache, a blkdev > file is just like any other, but with a 1:1 mapping between offset > and block). I mean, in Linux, the block device cache is unified. UNIX I believe did all its caching in a buffer cache, below the filesystem. > - Large block support. I can mount and run an 8K block size minix3 fs on > my 4K page system and it didn't require anything special in the fs. We Oh, and I don't have a Linux mkfs that makes minixv3 filesystems. I had an image kindly made for me because I don't use minix. If you want to test large block support, I won't email it to you though: you can just convert ext2 or ext3 to fsblock ;) - 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 read the FAQ at http://www.tux.org/lkml/
[patch 3/3] minix: convert to fsblock
Convert minix from buffer head to fsblock.
---
fs/minix/bitmap.c | 148 +--
fs/minix/file.c |6 -
fs/minix/inode.c| 172 ++--
fs/minix/itree_common.c | 227
fs/minix/itree_v1.c |7 -
fs/minix/itree_v2.c |7 -
fs/minix/minix.h| 17 ++-
7 files changed, 382 insertions(+), 202 deletions(-)
Index: linux-2.6/fs/minix/minix.h
===
--- linux-2.6.orig/fs/minix/minix.h
+++ linux-2.6/fs/minix/minix.h
@@ -1,4 +1,5 @@
#include
+#include
#include
#include
@@ -37,16 +38,18 @@ struct minix_sb_info {
int s_dirsize;
int s_namelen;
int s_link_max;
- struct buffer_head ** s_imap;
- struct buffer_head ** s_zmap;
- struct buffer_head * s_sbh;
+ struct fsblock_meta ** s_imap;
+ struct fsblock_meta ** s_zmap;
+ struct fsblock_meta * s_smblock;
struct minix_super_block * s_ms;
unsigned short s_mount_state;
unsigned short s_version;
};
-extern struct minix_inode * minix_V1_raw_inode(struct super_block *, ino_t,
struct buffer_head **);
-extern struct minix2_inode * minix_V2_raw_inode(struct super_block *, ino_t,
struct buffer_head **);
+extern struct minix_inode * minix_V1_raw_inode(struct super_block *, ino_t,
struct fsblock_meta **);
+extern void minix_put_raw_inode(struct super_block *sb, ino_t ino, struct
fsblock_meta *mblock, struct minix_inode *p);
+extern struct minix2_inode * minix_V2_raw_inode(struct super_block *, ino_t,
struct fsblock_meta **);
+extern void minix2_put_raw_inode(struct super_block *sb, ino_t ino, struct
fsblock_meta *mblock, struct minix2_inode *p);
extern struct inode * minix_new_inode(const struct inode * dir, int * error);
extern void minix_free_inode(struct inode * inode);
extern unsigned long minix_count_free_inodes(struct minix_sb_info *sbi);
@@ -60,8 +63,8 @@ extern void V2_minix_truncate(struct ino
extern void minix_truncate(struct inode *);
extern int minix_sync_inode(struct inode *);
extern void minix_set_inode(struct inode *, dev_t);
-extern int V1_minix_get_block(struct inode *, long, struct buffer_head *, int);
-extern int V2_minix_get_block(struct inode *, long, struct buffer_head *, int);
+extern int V1_minix_insert_mapping(struct address_space *, loff_t, size_t,
int);
+extern int V2_minix_insert_mapping(struct address_space *, loff_t, size_t,
int);
extern unsigned V1_minix_blocks(loff_t, struct super_block *);
extern unsigned V2_minix_blocks(loff_t, struct super_block *);
Index: linux-2.6/fs/minix/itree_common.c
===
--- linux-2.6.orig/fs/minix/itree_common.c
+++ linux-2.6/fs/minix/itree_common.c
@@ -1,31 +1,29 @@
/* Generic part */
typedef struct {
- block_t *p;
+ block_t *mem;
+ int offset;
block_t key;
- struct buffer_head *bh;
+ struct fsblock_meta *mblock;
} Indirect;
static DEFINE_RWLOCK(pointers_lock);
-static inline void add_chain(Indirect *p, struct buffer_head *bh, block_t *v)
+static inline void add_chain(Indirect *p, struct fsblock_meta *mblock, block_t
*mem, int offset)
{
- p->key = *(p->p = v);
- p->bh = bh;
+ p->mem = mem;
+ p->offset = offset;
+ p->key = mem[offset];
+ p->mblock = mblock;
}
static inline int verify_chain(Indirect *from, Indirect *to)
{
- while (from <= to && from->key == *from->p)
+ while (from <= to && from->key == from->mem[from->offset])
from++;
return (from > to);
}
-static inline block_t *block_end(struct buffer_head *bh)
-{
- return (block_t *)((char*)bh->b_data + bh->b_size);
-}
-
static inline Indirect *get_branch(struct inode *inode,
int depth,
int *offsets,
@@ -34,35 +32,43 @@ static inline Indirect *get_branch(struc
{
struct super_block *sb = inode->i_sb;
Indirect *p = chain;
- struct buffer_head *bh;
+ struct fsblock_meta *mblock;
*err = 0;
/* i_data is not going away, no lock needed */
- add_chain (chain, NULL, i_data(inode) + *offsets);
+ add_chain (chain, NULL, i_data(inode), *offsets);
if (!p->key)
- goto no_block;
+ goto out;
while (--depth) {
- bh = sb_bread(sb, block_to_cpu(p->key));
- if (!bh)
- goto failure;
+ void *data;
+
+ mblock = sb_mbread(sb, block_to_cpu(p->key));
+ if (!mblock) {
+ *err = -EIO;
+ goto out;
+ }
read_lock(&pointers_lock);
- if (!verify_chain(chain, p))
- goto changed;
- add_chain(++p, bh,
[patch 2/3] block_dev: convert to fsblock
Convert block_dev mostly to fsblocks.
---
fs/block_dev.c | 204 +++-
fs/buffer.c | 113 ++--
fs/super.c |2
include/linux/buffer_head.h |9 -
include/linux/fs.h | 29 ++
5 files changed, 225 insertions(+), 132 deletions(-)
Index: linux-2.6/fs/block_dev.c
===
--- linux-2.6.orig/fs/block_dev.c
+++ linux-2.6/fs/block_dev.c
@@ -16,7 +16,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -61,14 +63,14 @@ static void kill_bdev(struct block_devic
{
if (bdev->bd_inode->i_mapping->nrpages == 0)
return;
- invalidate_bh_lrus();
+ invalidate_bh_lrus(); /* XXX: this can go when buffers goes */
truncate_inode_pages(bdev->bd_inode->i_mapping, 0);
}
int set_blocksize(struct block_device *bdev, int size)
{
/* Size must be a power of two, and between 512 and PAGE_SIZE */
- if (size > PAGE_SIZE || size < 512 || !is_power_of_2(size))
+ if (size < 512 || !is_power_of_2(size))
return -EINVAL;
/* Size cannot be smaller than the size supported by the device */
@@ -92,7 +94,7 @@ int sb_set_blocksize(struct super_block
if (set_blocksize(sb->s_bdev, size))
return 0;
/* If we get here, we know size is power of two
-* and it's value is between 512 and PAGE_SIZE */
+* and it's value is >= 512 */
sb->s_blocksize = size;
sb->s_blocksize_bits = blksize_bits(size);
return sb->s_blocksize;
@@ -112,19 +114,12 @@ EXPORT_SYMBOL(sb_min_blocksize);
static int
blkdev_get_block(struct inode *inode, sector_t iblock,
- struct buffer_head *bh, int create)
+struct buffer_head *bh, int create)
{
if (iblock >= max_block(I_BDEV(inode))) {
if (create)
return -EIO;
-
- /*
-* for reads, we're just trying to fill a partial page.
-* return a hole, they will have to call get_block again
-* before they can fill it, and they will get -EIO at that
-* time
-*/
- return 0;
+return 0;
}
bh->b_bdev = I_BDEV(inode);
bh->b_blocknr = iblock;
@@ -132,6 +127,66 @@ blkdev_get_block(struct inode *inode, se
return 0;
}
+static int blkdev_insert_mapping(struct address_space *mapping, loff_t off,
+ size_t len, int create)
+{
+ sector_t blocknr;
+ struct inode *inode = mapping->host;
+ pgoff_t next, end;
+ struct pagevec pvec;
+ int ret = 0;
+
+ pagevec_init(&pvec, 0);
+ next = off >> PAGE_CACHE_SHIFT;
+ end = (off + len) >> PAGE_CACHE_SHIFT;
+ blocknr = off >> inode->i_blkbits;
+ while (next <= end && pagevec_lookup(&pvec, mapping, next,
+ min(end - next, (pgoff_t)PAGEVEC_SIZE))) {
+ unsigned int i;
+
+ for (i = 0; i < pagevec_count(&pvec); i++) {
+ struct fsblock *block;
+ struct page *page = pvec.pages[i];
+
+ BUG_ON(page->index != next);
+ BUG_ON(blocknr != pgoff_sector(next, inode->i_blkbits));
+ BUG_ON(!PageLocked(page));
+
+ if (blocknr >= max_block(I_BDEV(inode))) {
+ if (create)
+ ret = -ENOMEM;
+
+ /*
+* for reads, we're just trying to fill a
+* partial page. return a hole, they will
+* have to call in again before they can fill
+* it, and they will get -EIO at that time
+*/
+ continue; /* xxx: could be smarter, stop now */
+ }
+
+ block = page_blocks(page);
+ if (fsblock_subpage(block)) {
+ struct fsblock *b;
+ for_each_block(block, b) {
+ if (!test_bit(BL_mapped, &b->flags))
+ map_fsblock(b, blocknr);
+ blocknr++;
+ }
+ } else {
+ if (!test_bit(BL_mapped, &block->flags))
+ map_fsblock(block, blocknr);
+ blocknr++;
+ }
+ next++;
+ }
+ pagevec_release(&pvec);
+ }
+
+ re
[RFC] fsblock
I'm announcing "fsblock" now because it is quite intrusive and so I'd like to get some thoughts about significantly changing this core part of the kernel. fsblock is a rewrite of the "buffer layer" (ding dong the witch is dead), which I have been working on, on and off and is now at the stage where some of the basics are working-ish. This email is going to be long... Firstly, what is the buffer layer? The buffer layer isn't really a buffer layer as in the buffer cache of unix: the block device cache is unified with the pagecache (in terms of the pagecache, a blkdev file is just like any other, but with a 1:1 mapping between offset and block). There are filesystem APIs to access the block device, but these go through the block device pagecache as well. These don't exactly define the buffer layer either. The buffer layer is a layer between the pagecache and the block device for block based filesystems. It keeps a translation between logical offset and physical block number, as well as meta information such as locks, dirtyness, and IO status of each block. This information is tracked via the buffer_head structure. Why rewrite the buffer layer? Lots of people have had a desire to completely rip out the buffer layer, but we can't do that[*] because it does actually serve a useful purpose. Why the bad rap? Because the code is old and crufty, and buffer_head is an awful name. It must be among the oldest code in the core fs/vm, and the main reason is because of the inertia of so many and such complex filesystems. [*] About the furthest we could go is use the struct page for the information otherwise stored in the buffer_head, but this would be tricky and suboptimal for filesystems with non page sized blocks and would probably bloat the struct page as well. So why rewrite rather than incremental improvements? Incremental improvements are logically the correct way to do this, and we probably could go from buffer.c to fsblock.c in steps. But I didn't do this because: a) the blinding pace at which things move in this area would make me an old man before it would be complete; b) I didn't actually know exactly what it was going to look like before starting on it; c) I wanted stable root filesystems and such when testing it; and d) I found it reasonably easy to have both layers coexist (it uses an extra page flag, but even that wouldn't be needed if the old buffer layer was better decoupled from the page cache). I started this as an exercise to see how the buffer layer could be improved, and I think it is working out OK so far. The name is fsblock because it basically ties the fs layer to the block layer. I think Andrew has wanted to rename buffer_head to block before, but block is too clashy, and it isn't a great deal more descriptive than buffer_head. I believe fsblock is. I'll go through a list of things where I have hopefully improved on the buffer layer, off the top of my head. The big caveat here is that minix is the only real filesystem I have converted so far, and complex journalled filesystems might pose some problems that water down its goodness (I don't know). - data structure size. struct fsblock is 20 bytes on 32-bit, and 40 on 64-bit (could easily be 32 if we can have int bitops). Compare this to around 50 and 100ish for struct buffer_head. With a 4K page and 1K blocks, IO requires 10% RAM overhead in buffer heads alone. With fsblocks you're down to around 3%. - Structure packing. A page gets a number of buffer heads that are allocated in a linked list. fsblocks are allocated contiguously, so cacheline footprint is smaller in the above situation. - Data / metadata separation. I have a struct fsblock and a struct fsblock_meta, so we could put more stuff into the usually less used fsblock_meta without bloating it up too much. After a few tricks, these are no longer any different in my code, and dirty up the typing quite a lot (and I'm aware it still has some warnings, thanks). So if not useful this could be taken out. - Locking. fsblocks completely use the pagecache for locking and lookups. The page lock is used, but there is no extra per-inode lock that buffer has. Would go very nicely with lockless pagecache. RCU is used for one non-blocking fsblock lookup (find_get_block), but I'd really rather hope filesystems can tolerate that blocking, and get rid of RCU completely. (actually this is not quite true because mapping->private_lock is still used for mark_buffer_dirty_inode equivalent, but that's a relatively rare operation). - Coupling with pagecache metadata. Pagecache pages contain some metadata that is logically redundant because it is tracked in buffers as well (eg. a page is dirty if one or more buffers are dirty, or uptodate if all buffers are uptodate). This is great because means we can avoid that layer in some situations, but they can get out of sync. eg. if a filesystem writes a buffer out by hand, its pagecache page will stay dirty
Re: Rules on how to use sysfs in userspace programs
On Saturday 23 June 2007 08:49:47 Kay Sievers wrote: > On 6/22/07, Rob Landley <[EMAIL PROTECTED]> wrote: > > On Friday 08 June 2007 16:36:37 Greg KH wrote: > > > Over time there have been a number of problems when sysfs has changed > > > in "unexpected" ways. Here's a document that Kay wrote a while ago > > > that I'd like to add to the kernel Documentation directory to help > > > userspace programmers out. > > > > > > Any comments or critique of this is greatly appreciated. > > > > Still catching up from my laptop dying. > > > > I find the explanation of /sys/subsystem almost unintelligible. What > > will the new one actually look like? > > "It is planned to merge all three classification-directories into one > place at /sys/subsystem/, following the current layout of the > bus-directories." > > Means that /sys/subsystem/ will have a devices/ directory, full of > symlinks to the devices, all in a flat list. Subsytem-global attribute > files/directories are not mixed with the devices in the same directory > like in /sys/class, it will also not contain any hierarchy like the > layout of /sys/block. But will it still be possible to distinguish block devices from character devices when teaching mdev to quickly scan for devices to populate /dev in embedded systems using the "new" locations for things? > > If I want to find all block devices in the system, it looks like I should > > now look at /sys/subsystem/block. > > Yes, in this order (if you want to use it, but /sys/block will still be > there): /sys/subsytem/block/devices/* > /sys/class/block/* > /sys/block/*/* If /sys/block will still be there, and this is reliable and just "not deprecated _yet_", then life is good. I got the impression from the document that /sys/block was going away at some point. > > (And "subsystem" is not a variable here but > > the actual directory name? I presume it moved for Feng Shui reasons.) > > "one place at /sys/subsystem/" > > Yes, it will be all pretty consistent, the event-environment contains > $SUBSYSTEM, we will have /sys/subsystem/$SUBSYSTEM/devices/ directory > and at every device a symlink named "subsystem" pointing back to the > /sys/subsystem/$SUBSYSTEM/ directory. Which is good to know, but only useful if called from event context rather than scanning for devices from init scripts so it can mknod in /dev and fire off subsidiary scripts. > > If I want to find char devices, where do I look? /sys/subsystem... > > char? class? Is a char device now anything under /sys/subsystem that is > > _not_ in /sys/subsystem/block? (Minus bus devices?) Is there a specific > > directory for these? > > If /sys/subsystem exists, just look at /sys/subsystem/*/devices/*, you > will find every kernel device here, with exactly the logic to access > it. Every device with a "dev" file, it is a char device, unless > $SUBYSTEM=="block". Oh good. That last sentence contains the heuristic I need. > If /sys/subsystem/ doesn't exist, you have to search all through > /sys/bus/, /sys/class/, /sys/block/, every directory with completely No, only /sys/class and /sys/block. Currently, /sys/class contains char devices and /sys/block contains block devices. You don't have to invoke mknod for a bus. > different access pattern to find your device. You may want to look at > the udev code, it's all implemented there: > http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=udevtrigger.c;hb=H >EAD#l498 > > > This document is highly polluted with what NOT to do. > > Yeah, that's sysfs. It exports all the useless kernel implementation > details, so that _what_not_to_do_ is the biggest problem we have. :) If you document a specific subset of the data it exports and say "you can rely on this being there, lots of the rest is implementation details", then people have less cause to complain when the bits you haven't documented change. Right now, it's all undocumented and if you try to wade through the documentation it spends most of its time reminiscing about the bad old days of... nine months ago. > There is much too much internal stuff available here, that never can > be kept stable in the usual sense, as long as we allow to change > kernel/driver internals at the same time. Then document what is stable, please. > > I'm looking for a > > clear "what SHOULD I do", and it takes some wading to find it. > > (Historical cruft about what not to do is potentially a separate > > document, it's not useful for people learning this stuff now who weren't > > playing with the legacy mechanisms.) The description of /sys/subsystem > > spends so much time talking about old legacy issues it never gives a > > clear description of the new way of doing things, which is theoretically > > what this document is about... > > It was a first cut, I did months ago, and sure, it needs some work. I'm very interested in helping out with it, and updating mdev based on the documentation rather than the source code, but not until after OLS
Frequent SATA resets with sata_nv (fwd)
(Please cc me on replies) I have three samsung hdds (/sys/block/sda/device/model says SAMSUNG SP2504C) in a raid configuration. My system frequently (2-3x/day) experiences temporary lockups, which produce messages as below in my dmesg/syslog. The system recovers, but the hang is annoying to say the least. All three drives are connected to sata_nv ports. Oddly, it almost always happens on ata6 or ata7 (the second and third ports of that 4 port setup on my motherboard). There is an identical drive connected at ata5, but I've only once or twice seen it hit that drive. Googling around lkml.org, I found a few threads investigating what look like very similar problems, some of which never seemed to find the solution, but one of which came up with a fairly quick answer it seemed, namely that the drive's NCQ implementation was horked: http://lkml.org/lkml/2007/4/18/32 While I don't have older logs to verify exactly when this started, it was fairly recent, perhaps around my 2.6.20.1 to 2.6.21.1 kernel upgrade. Any other info or tests I can provide/run to help? Syslog snippet: Jun 21 10:35:23 cheetah kernel: ata6: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 0x400 next cpb count 0x0 next cpb idx 0x0 Jun 21 10:35:24 cheetah kernel: ata6: CPB 0: ctl_flags 0x9, resp_flags 0x0 Jun 21 10:35:24 cheetah kernel: ata6: timeout waiting for ADMA IDLE, stat=0x400 Jun 21 10:35:24 cheetah kernel: ata6: timeout waiting for ADMA LEGACY, stat=0x400 Jun 21 10:35:24 cheetah kernel: ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Jun 21 10:35:24 cheetah kernel: ata6.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 Jun 21 10:35:24 cheetah kernel: res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Jun 21 10:35:24 cheetah kernel: ata6: soft resetting port Jun 21 10:35:24 cheetah kernel: ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Jun 21 10:35:24 cheetah kernel: ata6.00: configured for UDMA/133 Jun 21 10:35:24 cheetah kernel: ata6: EH complete Jun 21 10:35:24 cheetah kernel: SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) Jun 21 10:35:24 cheetah kernel: sdb: Write Protect is off Jun 21 10:35:24 cheetah kernel: sdb: Mode Sense: 00 3a 00 00 Jun 21 10:35:24 cheetah kernel: SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA # lspci 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 01:0d.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) 03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 15) 05:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600 GT] (rev a2) -- -Cheetah "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG pubkey fingerprint: A57F B354 FD30 A502 795B 9637 3EF1 3F22 A85E 2AD1 - 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 read the FAQ at http://www.tux.org/lkml/
Re: Device hang when offlining a CPU due to IRQ misrouting
On Sat, Jun 23, 2007 at 06:45:05PM -0600, Eric W. Biederman wrote: > > Hmm. It looks like Siddha sent the wrong version of the patch. > The working tested version had an additional test to ensure > the mask and unmask methods were implemented. > > i.e. > + if (irq_desc[irq].chip->mask) > + irq_desc[irq].chip->mask(irq); > and > > + if (irq_desc[irq].chip->unmask) > + irq_desc[irq].chip->unmask(irq); > + > > Siddha think you can resend the correct version. Eric, In this version, I added the irq_has_action() check and hence removed the check which ensures the presence for mask/unmask. My tests showed that it was working fine. May be I am missing something. > > Rafael. Think you can add those two ifs and see if you test bed box > works? > > I'm still not convinced that we can make fixup_irqs work in general > but if we aren't going to yank it we should at least make it > consistent with the rest of the code. I agree. thanks, suresh - 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 read the FAQ at http://www.tux.org/lkml/
Re: Device hang when offlining a CPU due to IRQ misrouting
Andrew Morton <[EMAIL PROTECTED]> writes: > On Sun, 24 Jun 2007 01:54:52 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > >> On Wednesday, 20 June 2007 00:08, Siddha, Suresh B wrote: >> > On Tue, Jun 19, 2007 at 01:49:30PM -0700, Darrick J. Wong wrote: >> > > >> > > This fixes the problem! Hurrah! >> > >> > Great! Andrew, please include the appended patch in -mm. >> > >> > >> > Subject: [patch] x86_64, irq: use mask/unmask and proper locking in > fixup_irqs >> > From: Suresh Siddha <[EMAIL PROTECTED]> >> > >> > Force irq migration path during cpu offline, is not using proper >> > locks and irq_chip mask/unmask routines. This will result in >> > some races(especially the device generating the interrupt can see >> > some inconsistent state, resulting in issues like stuck irq,..). >> > >> > Appended patch fixes the issue by taking proper lock and >> > encapsulating irq_chip set_affinity() with a mask() before and an >> > unmask() after. >> > >> > This fixes a MSI irq stuck issue reported by Darrick Wong. >> > >> > There are several more general bugs in this area(irq migration in the >> > process context). For example, >> > >> > 1. Possibility of missing edge triggered irq. >> > 2. Reliable method of migrating level triggered irq in the process context. >> > >> > We plan to look and close these in the near future. >> >> This patch breaks hibernation on my Turion 64 X2 - based testbox (HPC >> nx6325). >> >> _cpu_down() just hangs as though there were a deadlock in there, 100% of the >> time. >> > > Thanks, I dropped it. Hmm. It looks like Siddha sent the wrong version of the patch. The working tested version had an additional test to ensure the mask and unmask methods were implemented. i.e. + if (irq_desc[irq].chip->mask) + irq_desc[irq].chip->mask(irq); and + if (irq_desc[irq].chip->unmask) + irq_desc[irq].chip->unmask(irq); + Siddha think you can resend the correct version. Rafael. Think you can add those two ifs and see if you test bed box works? I'm still not convinced that we can make fixup_irqs work in general but if we aren't going to yank it we should at least make it consistent with the rest of the code. Eric - 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 read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, "waste of time" is taking place here, but it's not for "pathname-based MAC" but for "wrongly posted messages", I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Well, I crated a Wiki page. If it helps, please feel free to use it. I mean I would like people to add your issues here. It's wiki, so you are welcome to modify everything. http://tomoyo.sourceforge.jp/wiki-e/?MAC-ISSUES If ml is better, I have no objections. I just wanted to help discussion. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is "let's make progress and help each other to make Linux better". Cheers, Toshiharu Harada - 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 read the FAQ at http://www.tux.org/lkml/
Re: Device hang when offlining a CPU due to IRQ misrouting
On Sun, Jun 24, 2007 at 01:54:52AM +0200, Rafael J. Wysocki wrote: > This patch breaks hibernation on my Turion 64 X2 - based testbox (HPC nx6325). > > _cpu_down() just hangs as though there were a deadlock in there, 100% of the > time. Does the patch at this URL work for you? http://marc.info/?l=linux-kernel&m=118228358826737&w=2 thanks, suresh - 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 read the FAQ at http://www.tux.org/lkml/
Re: [patch -mm 26/28] x86-64 block irq balancing for timer
On Sun, 2007-06-24 at 02:04 +0200, Andreas Kleen wrote: > Am Sat 23 Jun 2007 11:27:20 PM CEST schrieb Arjan van de Ven > <[EMAIL PROTECTED]>: > > > On Sat, 2007-06-23 at 13:32 +, Thomas Gleixner wrote: > >> plain text document attachment > >> (x86-64-clockevents-irq-balancing.patch) > >> From: Venki Pallipadi <[EMAIL PROTECTED]> > >> > >> Disable irq balancing on IRQ0. > > > > > > this patch is missing some rationale > > Several SIS chipsets lock up when you try to change affinity of IRQ #0 so we're protecting root against himself.. fair enough. probably wants a comment in the code -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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 read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.6.22-rc Kconfig troubles when using menuconfig
On Sat, 23 Jun 2007, Mauro Carvalho Chehab wrote: > Your patch seems OK to me, providing that we also add the Andreas patch: >--- a/drivers/net/Kconfig >+++ b/drivers/net/Kconfig >menuconfig NETDEV_1000 >- bool "Ethernet (1000 Mbit)" >+ tristate "Ethernet (1000 Mbit)" > depends on !UML >- default y > > menuconfig NETDEV_1 >- bool "Ethernet (1 Mbit)" >+ tristate "Ethernet (1 Mbit)" > depends on !UML >- default y I don't think this part is necessary. The only thing NETDEV_1000[0] depend on is UML, which is a boolean. Here is an alternate patch for this issue. I fix it by adding the dependencies of the menuconfig to the "if / endif" block the menuconfig controls. That way the menu doesn't turn into a tristate, which doesn't make a lot of sense. How can the menu be compiled as a module, when there is no code associated with it? -- Fix Kconfig dependency problems wrt boolean menuconfigs If one has a dependency chain (tristate)FOO depends on (bool)BAR depends on (tristate)BAZ, build problems will result. If BAZ=m, then BAR can be set y, which allows FOO=y. It's possible to have FOO=y && BAZ=m, which wouldn't be allowed if FOO depended directly on BAZ. In effect, the bool promotes the tristate from m to y. This ends up causing a problem with several menuconfigs that look like: menuconfig BAR bool depends on BAZ [tristate] if BAR config FOO tristate endif The solution used here is to add the dependencies of BAR to the if statement, so that items in the if block will gain a direct non-bool-promoted dependency on BAZ. This is how it would work if a menu was used instead of an if block. Signed-off-by: Trent Piepho <[EMAIL PROTECTED]> diff -r dfbe7cc4e21e drivers/atm/Kconfig --- a/drivers/atm/Kconfig Thu Jun 21 16:02:50 2007 -0700 +++ b/drivers/atm/Kconfig Sat Jun 23 16:41:05 2007 -0700 @@ -7,7 +7,7 @@ menuconfig ATM_DRIVERS depends on NETDEVICES && ATM default y -if ATM_DRIVERS +if ATM_DRIVERS && NETDEVICES && ATM config ATM_DUMMY tristate "Dummy ATM driver" diff -r dfbe7cc4e21e drivers/media/dvb/Kconfig --- a/drivers/media/dvb/Kconfig Thu Jun 21 16:02:50 2007 -0700 +++ b/drivers/media/dvb/Kconfig Sat Jun 23 16:42:28 2007 -0700 @@ -11,7 +11,7 @@ menuconfig DVB_CAPTURE_DRIVERS ---help--- Say Y to select Digital TV adapters -if DVB_CAPTURE_DRIVERS +if DVB_CAPTURE_DRIVERS && DVB_CORE comment "Supported SAA7146 based PCI Adapters" depends on DVB_CORE && PCI && I2C diff -r dfbe7cc4e21e drivers/media/radio/Kconfig --- a/drivers/media/radio/Kconfig Thu Jun 21 16:02:50 2007 -0700 +++ b/drivers/media/radio/Kconfig Sat Jun 23 16:42:44 2007 -0700 @@ -9,7 +9,7 @@ menuconfig RADIO_ADAPTERS ---help--- Say Y here to enable selecting AM/FM radio adapters. -if RADIO_ADAPTERS +if RADIO_ADAPTERS && VIDEO_DEV config RADIO_CADET tristate "ADS Cadet AM/FM Tuner" diff -r dfbe7cc4e21e drivers/media/video/Kconfig --- a/drivers/media/video/Kconfig Thu Jun 21 16:02:50 2007 -0700 +++ b/drivers/media/video/Kconfig Sat Jun 23 17:10:17 2007 -0700 @@ -11,7 +11,7 @@ menuconfig VIDEO_CAPTURE_DRIVERS webcams, analog TV, and hybrid analog/digital TV. Some of those devices also supports FM radio. -if VIDEO_CAPTURE_DRIVERS +if VIDEO_CAPTURE_DRIVERS && VIDEO_DEV config VIDEO_ADV_DEBUG bool "Enable advanced debug functionality" @@ -347,7 +347,7 @@ endmenu # encoder / decoder chips config VIDEO_VIVI tristate "Virtual Video Driver" - depends on VIDEO_V4L2 && !SPARC32 && !SPARC64 && PCI && VIDEO_DEV + depends on VIDEO_V4L2 && !SPARC32 && !SPARC64 && PCI select VIDEO_BUF default n ---help--- @@ -691,7 +691,7 @@ menuconfig V4L_USB_DRIVERS depends on USB default y -if V4L_USB_DRIVERS +if V4L_USB_DRIVERS && USB source "drivers/media/video/pvrusb2/Kconfig" diff -r dfbe7cc4e21e drivers/net/pcmcia/Kconfig --- a/drivers/net/pcmcia/KconfigThu Jun 21 16:02:50 2007 -0700 +++ b/drivers/net/pcmcia/KconfigSat Jun 23 16:45:44 2007 -0700 @@ -19,7 +19,7 @@ menuconfig NET_PCMCIA If unsure, say N. -if NET_PCMCIA +if NET_PCMCIA && PCMCIA config PCMCIA_3C589 tristate "3Com 3c589 PCMCIA support" - 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 read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, "waste of time" is taking place here, but it's not for "pathname-based MAC" but for "wrongly posted messages", I believe. I'm a relatively new to this ml, let me ask. Is this ml a place of judge or battle? (not to help or support?) Nothing is perfect, so we can work to make things to better, right? I have suggestions: Let's clarify issues first. - problems (or limitations) of pathname-based MAC - advantages of pathname-based MAC - how can pathname-based MAC supplement label based (Stephen, James and Kyle, please help) Let's start the arguments again if we get the issues. Threads should be definitely separated per issue and a assigning a chair may help. Above issues are independent of SELinux. We should not *compare* SELinux and AA, that can cause a problem. Every software has shortages that's why we need to work and we can make progress. For some issues we may need to compare them, in that case moderators would help. BTW I have posted a RFC of TOMOYO Linux that is another pathname-based MAC. http://lkml.org/lkml/2007/6/13/58 AA and TOMOYO Linux have BoF sessions at OLS2007, so it would be a great opportunity to *talk* over the issues. What I want to say is "let's make progress and help each other to make Linux better". Thank you, Toshiharu Harada Chris Wright wrote: > * Chris Mason ([EMAIL PROTECTED]) wrote: >> I'm sure people there will have a different versions of events. The >> one part that was discussed was if pathname based security was >> useful, and a number of the people in the room (outside of >> novell) said it was. Now, it could be that nobody wanted to argue >> anymore, since most opinions had come out on one list or another by >> then. > > Indeed. The trouble is that's too high level compared with the actual > implementation details. AA is stalled because it has failed to get > VFS support for it's model. I don't see a nice way out unless it > changes it's notion of policy language (globbing is the tough one) > or gets traction to pass dentry/vfsmount all the way down. Paths are > completely relevant for security, esp. when considering the parent dir > and the leaf (as in forward lookup case). Retroactively creating the > full path is at the minimum ugly, and in the worst case can be insecure > (yes AA has taken many measures to mitigate that insecurity). > >> But as someone who doesn't use either SElinux or AA, I really hope >> we can get past the part of the debate where: >> >> while(1) >> AA) we think we're making users happy with pathname security >> SELINUX) pathname security sucks > > Yes. Please. Both parties are miserably failing the sanity test. > Doing the same thing over and over and expecting different results. > > AA folks: deal with the VFS issues that your patchset have in a palatable > way (which does not include passing NULL when it's inconvenient to > do otherwise). You've already missed an opportunity with Christoph's > suggestions for changes in NFS. I know you've considered many alternative > approaches and consistently hit dead ends. But please note, if you > have coded yourself into a corner because of your policy language, > that's your issue to solve, not ours. > > SELinux folks: do something useful rather than quibbling over the TCSEC > definition of MAC and AA's poor taste in marketing literature. Here's > some suggestions: > > 1) Make SELinux usable (it's *still* the number one complaint). While > this is a bit of a cheap shot, it really is one of the core reasons AA > advocates exist. > 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA. > 3) Write an effective exploit against AA that demonstrates the fundamental > weakness of the model (better make sure it's not also an issue for > targetted policy). -- Toshiharu Harada [EMAIL PROTECTED] - 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 read the FAQ at http://www.tux.org/lkml/
Re: [patch -mm 26/28] x86-64 block irq balancing for timer
Am Sat 23 Jun 2007 11:27:20 PM CEST schrieb Arjan van de Ven <[EMAIL PROTECTED]>: On Sat, 2007-06-23 at 13:32 +, Thomas Gleixner wrote: plain text document attachment (x86-64-clockevents-irq-balancing.patch) From: Venki Pallipadi <[EMAIL PROTECTED]> Disable irq balancing on IRQ0. this patch is missing some rationale Several SIS chipsets lock up when you try to change affinity of IRQ #0 -Andi - 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 read the FAQ at http://www.tux.org/lkml/
Re: Device hang when offlining a CPU due to IRQ misrouting
On Sun, 24 Jun 2007 01:54:52 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > On Wednesday, 20 June 2007 00:08, Siddha, Suresh B wrote: > > On Tue, Jun 19, 2007 at 01:49:30PM -0700, Darrick J. Wong wrote: > > > > > > This fixes the problem! Hurrah! > > > > Great! Andrew, please include the appended patch in -mm. > > > > > > Subject: [patch] x86_64, irq: use mask/unmask and proper locking in > > fixup_irqs > > From: Suresh Siddha <[EMAIL PROTECTED]> > > > > Force irq migration path during cpu offline, is not using proper > > locks and irq_chip mask/unmask routines. This will result in > > some races(especially the device generating the interrupt can see > > some inconsistent state, resulting in issues like stuck irq,..). > > > > Appended patch fixes the issue by taking proper lock and > > encapsulating irq_chip set_affinity() with a mask() before and an > > unmask() after. > > > > This fixes a MSI irq stuck issue reported by Darrick Wong. > > > > There are several more general bugs in this area(irq migration in the > > process context). For example, > > > > 1. Possibility of missing edge triggered irq. > > 2. Reliable method of migrating level triggered irq in the process context. > > > > We plan to look and close these in the near future. > > This patch breaks hibernation on my Turion 64 X2 - based testbox (HPC nx6325). > > _cpu_down() just hangs as though there were a deadlock in there, 100% of the > time. > Thanks, I dropped it. - 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 read the FAQ at http://www.tux.org/lkml/
Re: Device hang when offlining a CPU due to IRQ misrouting
On Wednesday, 20 June 2007 00:08, Siddha, Suresh B wrote: > On Tue, Jun 19, 2007 at 01:49:30PM -0700, Darrick J. Wong wrote: > > > > This fixes the problem! Hurrah! > > Great! Andrew, please include the appended patch in -mm. > > > Subject: [patch] x86_64, irq: use mask/unmask and proper locking in fixup_irqs > From: Suresh Siddha <[EMAIL PROTECTED]> > > Force irq migration path during cpu offline, is not using proper > locks and irq_chip mask/unmask routines. This will result in > some races(especially the device generating the interrupt can see > some inconsistent state, resulting in issues like stuck irq,..). > > Appended patch fixes the issue by taking proper lock and > encapsulating irq_chip set_affinity() with a mask() before and an > unmask() after. > > This fixes a MSI irq stuck issue reported by Darrick Wong. > > There are several more general bugs in this area(irq migration in the > process context). For example, > > 1. Possibility of missing edge triggered irq. > 2. Reliable method of migrating level triggered irq in the process context. > > We plan to look and close these in the near future. This patch breaks hibernation on my Turion 64 X2 - based testbox (HPC nx6325). _cpu_down() just hangs as though there were a deadlock in there, 100% of the time. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] fbdev: uvesafb driver
On Sun, 24 Jun 2007 01:20:33 +0200 Michal Januszewski <[EMAIL PROTECTED]> wrote: > > > +config FB_UVESA > > > + tristate "Userspace VESA VGA graphics support" > > > + depends on FB && CONNECTOR > > > > These dependencies are insufficient. > > What exactly is missing here? A dep on X86? Yes. From your other comments it appears that a dependency on X86_32 is needed. > This would indicate the > arches on which the driver has actually been tested. But which arches > are supported and which aren't is, in the end, up to the userspace helper. The other architectures won't compile: they don't have mtrr.h - 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 read the FAQ at http://www.tux.org/lkml/
[PATCH] HFSPlus: simplify inode mode settting logic
From: Wyatt Banks <[EMAIL PROTECTED]>
HFSPlus: Fix broken inode mode setting logic. Fix broken umask mount option.
Signed-off-by: Wyatt Banks <[EMAIL PROTECTED]>
---
Patched against 2.6.21.5
hfsplus_cat_read_inode() decides if the selected inode is a directory or not.
It then sets the 3rd parameter of hfsplus_get_perms() accordingly. Inside
hfsplus_get_perms() it again decides based on its 3rd parameter if the inode
is a directory or not. Besides this redundancy, mode is the BSD file type and
mode
bits (see Apple TechNote 1150 for details) and is never 0. This makes a large
portion of the branching logic unused. What actually does happen in the
branching
is that the UGO mode bits are combined with the directory or regular file bit
after
the 2nd decision and this resultant mode is assigned to the inode. This also
loses
suid, sgid, sticky, pipe, fifo, etc.
This patch also fixes the umask mount option as a result. I figured instead of
filing a bug report, I'd just go ahead and fix it. :-)
diff -uprN -X linux-2.6.21.5/Documentation/dontdiff
linux-2.6.21.5/fs/hfsplus/inode.c linux-2.6.21.5-devel/fs/hfsplus/inode.c
--- linux-2.6.21.5/fs/hfsplus/inode.c 2007-06-11 14:37:06.0 -0400
+++ linux-2.6.21.5-devel/fs/hfsplus/inode.c 2007-06-23 18:23:57.0
-0400
@@ -173,7 +173,7 @@ out:
return NULL;
}
-static void hfsplus_get_perms(struct inode *inode, struct hfsplus_perm *perms,
int dir)
+static void hfsplus_get_perms(struct inode *inode, struct hfsplus_perm *perms)
{
struct super_block *sb = inode->i_sb;
u16 mode;
@@ -188,14 +188,7 @@ static void hfsplus_get_perms(struct ino
if (!inode->i_gid && !mode)
inode->i_gid = HFSPLUS_SB(sb).gid;
- if (dir) {
- mode = mode ? (mode & S_IALLUGO) :
- (S_IRWXUGO & ~(HFSPLUS_SB(sb).umask));
- mode |= S_IFDIR;
- } else if (!mode)
- mode = S_IFREG | ((S_IRUGO|S_IWUGO) &
- ~(HFSPLUS_SB(sb).umask));
- inode->i_mode = mode;
+ inode->i_mode = mode & ~(HFSPLUS_SB(sb).umask);
HFSPLUS_I(inode).rootflags = perms->rootflags;
HFSPLUS_I(inode).userflags = perms->userflags;
@@ -415,7 +408,7 @@ int hfsplus_cat_read_inode(struct inode
/* panic? */;
hfs_bnode_read(fd->bnode, &entry, fd->entryoffset,
sizeof(struct hfsplus_cat_folder));
- hfsplus_get_perms(inode, &folder->permissions, 1);
+ hfsplus_get_perms(inode, &folder->permissions);
inode->i_nlink = 1;
inode->i_size = 2 + be32_to_cpu(folder->valence);
inode->i_atime = hfsp_mt2ut(folder->access_date);
@@ -435,7 +428,7 @@ int hfsplus_cat_read_inode(struct inode
hfsplus_inode_read_fork(inode, HFSPLUS_IS_DATA(inode) ?
&file->data_fork : &file->rsrc_fork);
- hfsplus_get_perms(inode, &file->permissions, 0);
+ hfsplus_get_perms(inode, &file->permissions);
inode->i_nlink = 1;
if (S_ISREG(inode->i_mode)) {
if (file->permissions.dev)
-
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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] fbdev: uvesafb driver
On Sat, Jun 23, 2007 at 11:35:57AM -0700, Andrew Morton wrote:
> On Sat, 23 Jun 2007 12:52:43 +0200 Michal Januszewski <[EMAIL PROTECTED]>
> wrote:
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 403dac7..5cc03f9 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -585,6 +585,24 @@ config FB_TGA
> >
> > Say Y if you have one of those.
> >
> > +config FB_UVESA
> > + tristate "Userspace VESA VGA graphics support"
> > + depends on FB && CONNECTOR
>
> These dependencies are insufficient.
What exactly is missing here? A dep on X86? This would indicate the
arches on which the driver has actually been tested. But which arches
are supported and which aren't is, in the end, up to the userspace helper.
> > +static struct cb_id uvesafb_cn_id = {
> > + .idx = CN_IDX_V86D,
> > + .val = CN_VAL_V86D_UVESAFB
> > +};
> > +static struct sock *nls;
> > +static char v86d_path[PATH_MAX] = "/sbin/v86d";
>
> Remove the PATH_MAX, save some memory.
>
> Oh, it gets set via sysfs. hrm.
Hmm, I guess I could make it a hard-coded value, but paths to userspace
helpers should generally be configurable, right?
> Now I'm wondering what this code actually does. It would be nice to have
> an overall design and implementation description in the changelog so we
> don't have to reverse-engineer your thoughts from your implementation...
OK, I'll include a more detailed description in the next round of the
patches.
> > +#ifdef __i386__
>
> CONFIG_X86 would be more typical.
>
> Be aware that CONFIG_X86 is true for both i386 and x86_64. You don't state
> whether this code works on x86_64. If it can, it should.
AFAIK, it can't. PMI code is meant to be run in 32-bit protected mode.
I'll add a note about this to the patch and change __i386__ to
CONFIG_X86_32.
> You might care to cc "H. Peter Anvin" <[EMAIL PROTECTED]> on the next version
> of this patch - he's a whizz at this sort of low-level x86 bios
> communication stuff.
Thanks, I'll do that.
> > + if (!request_mem_region(info->fix.smem_start, info->fix.smem_len,
> > + "uvesafb")) {
> > + printk(KERN_WARNING "uvesafb: cannot reserve video memory at "
> > + "0x%lx\n", info->fix.smem_start);
> > + /* We cannot make this fatal. Sometimes this comes from magic
> > + spaces our resource handlers simply don't know about. */
>
> so... what happens? The driver starts altering mrmory regions which it
> doesn't own?
Fixed. This was a leftover from vesafb.c. Are there any reasons for not
fixing it there as well?
> > +#ifndef MODULE
> > +static int __devinit uvesafb_setup(char *options)
> > +{
> > + char *this_opt;
> > +
> > + if (!options || !*options)
> > + return 0;
> > +
> > + while ((this_opt = strsep(&options, ",")) != NULL) {
> > + if (!*this_opt) continue;
> > +
> > + if (!strcmp(this_opt, "redraw"))
> > + ypan = 0;
> > + else if (!strcmp(this_opt, "ypan"))
> > + ypan = 1;
> > + else if (!strcmp(this_opt, "ywrap"))
> > + ypan = 2;
> > + else if (!strcmp(this_opt, "vgapal"))
> > + pmi_setpal = 0;
> > + else if (!strcmp(this_opt, "pmipal"))
> > + pmi_setpal = 1;
> > + else if (!strncmp(this_opt, "mtrr:", 5))
> > + mtrr = simple_strtoul(this_opt+5, NULL, 0);
> > + else if (!strcmp(this_opt, "nomtrr"))
> > + mtrr = 0;
> > + else if (!strcmp(this_opt, "nocrtc"))
> > + nocrtc = 1;
> > + else if (!strcmp(this_opt, "noedid"))
> > + noedid = 1;
> > + else if (!strcmp(this_opt, "noblank"))
> > + blank = 0;
> > + else if (!strncmp(this_opt, "vtotal:", 7))
> > + vram_total = simple_strtoul(this_opt + 7, NULL, 0);
> > + else if (!strncmp(this_opt, "vremap:", 7))
> > + vram_remap = simple_strtoul(this_opt + 7, NULL, 0);
> > + else if (!strncmp(this_opt, "maxhf:", 6))
> > + maxhf = simple_strtoul(this_opt + 6, NULL, 0);
> > + else if (!strncmp(this_opt, "maxvf:", 6))
> > + maxvf = simple_strtoul(this_opt + 6, NULL, 0);
> > + else if (!strncmp(this_opt, "maxclk:", 7))
> > + maxclk = simple_strtoul(this_opt + 7, NULL, 0);
> > + else if (!strncmp(this_opt, "vbemode:", 8))
> > + vbemode = simple_strtoul(this_opt + 8, NULL,0);
> > + else if (this_opt[0] >= '0' && this_opt[0] <= '9') {
> > + mode_option = this_opt;
> > + } else {
> > + printk(KERN_WARNING
> > + "uvesafb: unrecognized option %s\n", this_opt);
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +#endif /* !MODULE */
>
> The #ifdef MODULE
Re: [PATCH 1/7] ICH Force HPET: Make generic time capable of switching broadcast timer
On Sat, 2007-06-23 at 09:52 -0700, Andrew Morton wrote: > I _think_ what's going on here is that your code will go and poke the > hardware to enable the hpet even f the BIOS decided to hide its presence. > Is that correct? If so, perhaps the changelog should mention this > explicitly. > > > Applies over linux-2.6.22-rc4-mm2 + > > tglx's patch-2.6.22-rc4-mm2-hrt4 patch > > Oh. Well that tears that then. > > Thomas, can I assume that you'll send all this stuff back at me? I sent out a V3 queue today, but the aggregate of my queue and Venki's HPET stuff + HPET force enable for non Intel chip sets is available as a full queue here: http://www.tglx.de/projects/hrtimers/2.6.22-rc4-mm2/patch-2.6.22-rc4-mm2-hrt6.patches.tar.bz2 I can resend the 40 patches if you want, but they are out on LKML already (-hrt and the hpet ones), so there is little value to spam everyones inbox with the same stuff again. tglx - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
On 23/06/07, Grozdan Nikolov <[EMAIL PROTECTED]> wrote: On Saturday 23 June 2007 20:54, jimmy bahuleyan wrote: [snip] > I'm not a kernel developer myself, but i think there are lots of > resources on the internet where you can read watered down versions of > discussions happening on this list. If there are I'm unaware of those, thanks for the hint though A few places: The LinuxChanges page at kernelnewbies: http://kernelnewbies.org/LinuxChanges The kernel section of LWN: http://lwn.net/Kernel/ Kerneltrap: http://kerneltrap.org/ Kernel Traffic (unfortunately no longer updated): http://kerneltraffic.org/ And then you have list archives like : http://lkml.org/ http://marc.info/?l=linux-kernel http://www.uwsg.iu.edu/hypermail/linux/kernel/index.html -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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 read the FAQ at http://www.tux.org/lkml/
Re: Fix signalfd interaction with thread-private signals
On Sat, 2007-06-23 at 16:05 +1000, Benjamin Herrenschmidt wrote: > On Fri, 2007-06-22 at 17:12 -0700, Davide Libenzi wrote: > > Wasn't it you that bitched (just a few days ago) because multiple > > threads > > could not use the same signalfd and they (by your initial thought) had > > to > > create one per thread? > > He said multiple process and you say multiple threads... > > If signalfd isn't attached to any context, it would then be useable by > all threads in a process, delivering them their private signals and the > process shared signals. Makes sense to me. > > By removing that context thing, you lose the ability to listen to some > other -process- signals, which is probably a bad idea in the first place > anyway... if you're going to do that, use ptrace (yuck) :-) > > Now, you -might- have valid uses for that later ability, but if not, it > then makes some sense to only "attach" when an actual read or poll is > done and only for the duration of that read/poll and only for that > reader/poller (not the whole signalfd instance). > > I think that's what Nicholas means... and it may even simplify the code. > That is what I was suggesting, but I don't understand the internals of Linux signal delivery enough to know if it is possible without unpleasant contortions to make it work. -- Nicholas Miell <[EMAIL PROTECTED]> - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ALSA: use __devexit_p
This reminds me...
Someone needs to go through ALSA and audit all delays executed via
$FOO_interruptible().
Several delays within ALSA wait for hardware conditions, and do not
check for signals pending, which means that the wait-for-condition loop
becomes a busy loop:
while (1) {
foo = read_hardware()
if (foo & interesting_bits)
break;
schedule_timeout_interruptible(1);
}
The proper fix is (a) remove "_interruptible" [recommended] or (b) check
for signals.
grep'ing for "_interruptible" quickly finds several such ALSA bugs.
Jeff
-
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 read the FAQ at http://www.tux.org/lkml/
Re: SATA RAID5 speed drop of 100 MB/s
Carlo Wood wrote: Is it possible that the measurement with "hdparm -tT" returns a higher value for some setting, but that the over-all real-life performance drops? IN THEORY, RAID performance should /increase/ due to additional queued commands available to be sent to the drive. NCQ == command queueing == sending multiple commands to the drive, rather than one-at-a-time like normal. But hdparm isn't the best test for that theory, since it does not simulate the transactions like real-world MD device usage does. We have seen buggy NCQ firmwares where performance decreases, so it is possible that NCQ just isn't good on your drives. Jeff - 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 read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
On Sat, 23 Jun 2007, Satyam Sharma wrote: > On 6/23/07, Trent Piepho <[EMAIL PROTECTED]> wrote: > > [...] > > What you have is tristate depends on bool depends on tristate. The bool > > between the two tristates "promotes" the first tristate from m to y. > > [...] > > Or another way, add the dependencies of the menuconfig to the if statement: > > diff -r dfbe7cc4e21e drivers/media/video/Kconfig > > --- a/drivers/media/video/Kconfig Thu Jun 21 16:02:50 2007 -0700 > > +++ b/drivers/media/video/Kconfig Fri Jun 22 13:10:43 2007 -0700 > > @@ -691,7 +691,7 @@ menuconfig V4L_USB_DRIVERS > > depends on USB > > default y > > > > -if V4L_USB_DRIVERS > > +if V4L_USB_DRIVERS && USB > > > > source "drivers/media/video/pvrusb2/Kconfig" > > > > Now all the usb drivers will gain USB as a dependency directly and can't be > > set to something higher than USB. > > Ok, so we add this as solution 2.(c) to the reply I just sent to Jan :-) > > But I still prefer 2.(b) -- making the config scripts intelligent so that if a > given "menuconfig FOO depends on BAR", then all the "config BAZ"s > inside this menuconfig also automatically "depend on" BAR too. Of course, there currently is no "inside" a menuconfig. You would have to do something like make everything inside an "if FOO / endif" gain not just a dependency on FOO, but also gain a dependency on all of FOO's dependencies. > This is simpler in the long run because it requires least amount > (actually none) of redundant typing and would continue to work in > the future if/when the: > > menuconfig FOO > if FOO > ... > endif # FOO > > idiom is converted to an: > > configmenu FOO > ... > endconfigmenu # FOO > > kind of idiom ... Like that I suggested here? http://article.gmane.org/gmane.linux.kernel/524823 Basically, make menuconfig work like menu does, except the menu itself can be turned on and off. Instead of having menuconfig work like a config, but with some kind of "menu" hint. It seems like the former is more in line with what menuconfig is actually used for. - 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 read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.6.22-rc Kconfig troubles when using menuconfig
Hi Jan, Your patch seems OK to me, providing that we also add the Andreas patch: --- Correct Kconfig to avoid compile errors like drivers/built-in.o: In function `sn9c102_usb_disconnect': sn9c102_core.c:(.text+0x8d840): undefined reference to `usb_get_dev' Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 4cca551..4754d98 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -687,7 +687,7 @@ config VIDEO_CAFE_CCIC # menuconfig V4L_USB_DRIVERS - bool "V4L USB devices" + tristate "V4L USB devices" depends on USB default y Em Sáb, 2007-06-23 às 09:20 +0200, Jan Engelhardt escreveu: > Anyone with strong objections to this patch? (Hopefully) fixes the > kconfig issue for now. > > > Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> Acked-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]> (for both Andreas and your patch) -- Cheers, Mauro - 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5 v2] Convert all tasklets to workqueues V2
Hi, Applied this to 2.6.21-5 along with an older version of dyntick and cfs v18, durring boot I got: [ 54.154077] hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb 81004ec55628 err -38 [ 54.154086] hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb 81004ec55628 err -38 [ 54.168147] BUG: at kernel/mutex.c:132 __mutex_lock_common() [ 54.170801] [ 54.170802] Call Trace: [ 54.175975] [] check_preempt_curr_fair+0x70/0x90 [ 54.178694] [] __mutex_lock_slowpath+0x6f/0x200 [ 54.181417] [] mutex_lock+0x19/0x20 [ 54.184165] [] flush_workqueue+0x31/0x50 [ 54.186975] [] tasklet_disable+0x15/0x20 [ 54.189829] [] :bluetooth:hci_cc_host_ctl+0x17f/0x240 [ 54.192767] [] :bluetooth:hci_event_packet+0x139c/0x1560 [ 54.195712] [] :bluetooth:hci_send_to_sock+0x134/0x180 [ 54.198657] [] :bluetooth:hci_rx_task+0x9f/0x270 [ 54.201588] [] work_tasklet_exec+0x0/0x50 [ 54.204473] [] work_tasklet_exec+0x3c/0x50 [ 54.207282] [] run_workqueue+0x94/0x130 [ 54.210032] [] worker_thread+0x149/0x190 [ 54.212781] [] default_wake_function+0x0/0x10 [ 54.215539] [] worker_thread+0x0/0x190 [ 54.218241] [] kthread+0xd3/0x110 [ 54.220880] [] child_rip+0xa/0x12 [ 54.223484] [] kthread+0x0/0x110 [ 54.226075] [] child_rip+0x0/0x12 Has this patch uncovered a problem in bluetooth or is it a problem with the patch? TIA, Ed Tomlinson On Friday 22 June 2007 14:20, Steven Rostedt wrote: > -- > > This is version 2 of the tasklet to workqueue conversion. > > Changes from version 1. > > - removed config option and simply replace the old implementation > with the work queue one (recommended by Ingo Molnar). > > - replaced clear_bit with test_and_clear_bit to avoid the race of > executing the tasklet function twice. (thanks to Oleg Nesterov > for pointing that out). > > - Removed most of the pr_debug prints. (Kept one) > (recommended by Ingo Molnar) > > - Removed call to softirq_init. > > - Added Author credit to Dipankar Sarma for the RCU tasklet to > softirq conversion. > > - Tested on my Powerbook to add another arch to the mix :-) > Funny that booting with this change was the first time that > the bcm43xx didn't get stuck for several seconds on bootup. > It's also one of the few drivers that use tasklet_disable_nosync. > So either this shows that the change fixed something, or that > it broke something (or was just a fluke). > > > -- Steve > > - > 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 read the FAQ at http://www.tux.org/lkml/ > > - 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 read the FAQ at http://www.tux.org/lkml/
i2c_adapter unrecognized stepping
Booting the 2.6.20.14 kernel on a Sun X4600M2 genreates the following messgae about unrecognized stepping. Is this a known issue and/or problem? Thanks. ... kernel: Initializing CPU#15 kernel: Calibrating delay using timer specific routine.. 5186.68 BogoMIPS (lpj=10373366) kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) kernel: CPU: L2 Cache: 1024K (64 bytes/line) kernel: CPU 15/f -> Node 7 kernel: CPU: Physical Processor ID: 7 kernel: CPU: Processor Core ID: 1 kernel: Dual-Core AMD Opteron(tm) Processor 8218 stepping 02 kernel: CPU 15: Syncing TSC to CPU 0. kernel: CPU 15: synchronized TSC with CPU 0 (last diff -38 cycles, maxerr 2285 cycles) kernel: Brought up 16 CPUs ... kernel: i2c_adapter i2c-1: : Unrecognized stepping 0x45. Defaulting to ADM1026. kernel: i2c_adapter i2c-1: : Unrecognized stepping 0x45. Defaulting to ADM1026. kernel: i2c_adapter i2c-1: : Found version/stepping 0x46. Assuming generic ADM1026. -- Stuart Anderson [EMAIL PROTECTED] http://www.ligo.caltech.edu/~anderson - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
On Sat, 23 Jun 2007 16:13:55 -0600 "David Kane" <[EMAIL PROTECTED]> wrote: > The real innotation in Linux is that it is open source and yet popular > enough that there are versions that even a windoze user could easily pick > up. I think that is more a product of its time than the software. It isn't the first openly available Unix-like OS. The others such as UZI and OMU died because there wasn't the internet in its modern form to keep them going, share them and build communities. - 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 read the FAQ at http://www.tux.org/lkml/
Re: SATA Harddisk speed drop of 100 MB/s
Andrew Morton wrote: Please see http://bugzilla.kernel.org/show_bug.cgi?id=8636 In that report a pretty large slowdown with CFQ has been identified. Jens has plunked a patch in there (Comment #50) and then ran away on vacation. If someone can test that patch and demonstrate its goodness, I'll queue it up, thanks. This has unfortunately split up into two threads. I identified the root cause of the slowdown as NCQ in the thread "Re: SATA RAID5 speed drop of 100 MB/s" on LKML. Jeff - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] saa7134: fix thread shutdown handling
Em Sáb, 2007-06-23 às 09:54 -0700, Andrew Morton escreveu:
> > On Thu, 21 Jun 2007 14:45:22 -0400 Jeff Mahoney <[EMAIL PROTECTED]> wrote:
> > This patch changes the test for the thread pid from >= 0 to > 0.
> >
> > When the saa8134 driver initialization fails after a certain point,
> > it goes through the complete shutdown process for the driver. Part
> > of shutting it down includes tearing down the thread for tv audio.
> >
> > The test for tearing down the thread tests for >= 0. Since the dev
> > structure is kzalloc'd, the test will always be true if we haven't
> > tried to start the thread yet. We end up waiting on pid 0 to complete,
> > which will never happen, so we lock up.
> >
> > This bug was observed in Novell Bugzilla 284718, when request_irq()
> > failed.
> >
> > Signed-off-by: Jeff Mahoney <[EMAIL PROTECTED]>
> >
> > ---
> >
> > drivers/media/video/saa7134/saa7134-tvaudio.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- a/drivers/media/video/saa7134/saa7134-tvaudio.c 2007-06-12
> > 15:45:16.0 -0400
> > +++ b/drivers/media/video/saa7134/saa7134-tvaudio.c 2007-06-15
> > 14:16:14.0 -0400
> > @@ -1005,7 +1005,7 @@
> > int saa7134_tvaudio_fini(struct saa7134_dev *dev)
> > {
> > /* shutdown tvaudio thread */
> > - if (dev->thread.pid >= 0) {
> > + if (dev->thread.pid > 0) {
> > dev->thread.shutdown = 1;
> > wake_up_interruptible(&dev->thread.wq);
> > wait_for_completion(&dev->thread.exit);
> >
>
> This is no longer applicable to the dvb devel tree, because this code has
> been converted to the kthread API.
>
> However I guess we do want this in 2.6.22 and in 2.6.21.x. Mauro, if
> that's OK, do you want me to do the merges?
Yes, please, Andrew. I'm OK on merging this for the -stable trees.
>
--
Cheers,
Mauro
-
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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
The real innotation in Linux is that it is open source and yet popular enough that there are versions that even a windoze user could easily pick up. David Kane On 6/23/07, Carlo Wood <[EMAIL PROTECTED]> wrote: On Sat, Jun 23, 2007 at 04:46:08PM +0100, Alan Cox wrote: > Now if you want really innovative OS work go look in the lab or at > projects most people have never heard of and don't run. Hey, I heard of one. I got a few friends that are sitting in an IRC channel and have been working on a complete new OS from scratch for like 10 years now (kernel, filesystem, graphics drivers, libraries - everything). I consider them to be totally nuts of course. When I ask them why are you still doing this? Can't you use linux? Then the answer is that there are still companies interested in operating systems like that, precisely because they are not well- known. It would be pretty hard to exploit vulnerabilities in such a system (or that is their explanation anyway). -- Carlo Wood <[EMAIL PROTECTED]> - 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 read the FAQ at http://www.tux.org/lkml/ - 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 read the FAQ at http://www.tux.org/lkml/
Re: make xconfig failure on 2.6.21.5
On Sun, Jun 24, 2007 at 12:14:49AM +0530, jimmy bahuleyan wrote: > > Hi, > > I have a Kubuntu 7.04 distro with Qt4 development packages installed. > Trying to do a 'make xconfig' fails with: > > HOSTCC scripts/basic/fixdep > HOSTCC scripts/basic/docproc > CHECK qt > * > * Unable to find the QT installation. Please make sure that > * the QT development package is correctly installed and > * either install pkg-config or set the QTDIR environment > * variable to the correct location. > * > HOSTCC scripts/kconfig/conf.o > sed < scripts/kconfig/lkc_proto.h > scripts/kconfig/lkc_defs.h > 's/P(\([^,]*\),.*/#define \1 (\*\1_p)/' > HOSTCC scripts/kconfig/kconfig_load.o > HOSTCC scripts/kconfig/kxgettext.o > SHIPPED scripts/kconfig/zconf.tab.c > SHIPPED scripts/kconfig/lex.zconf.c > SHIPPED scripts/kconfig/zconf.hash.c > HOSTCC scripts/kconfig/zconf.tab.o > make[1]: *** No rule to make target `scripts/kconfig/.tmp_qtcheck', > needed by `scripts/kconfig/qconf.o'. Stop. > make: *** [xconfig] Error 2 > > > Is this a problem with my setup or that kbuild/kconfig can't handle Qt4? xconfig does not yet support qt4 (IIRC). So you will need qt3 packages to build xconfig. Patches to introduce qt4 config without breaking qt3 config are appreciated... Sam - 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues
On Sat, 23 Jun 2007, Steven Rostedt wrote: > > > > On Sat, 23 Jun 2007, Andrew Morton wrote: > > > > > > Anyway. Please fix the many correct warnings which checkpatch.pl > > > generates > > > > Actually, please don't. > > You sure? If I were to do this recommended fix, I would simply add > another patch. One to do the fixes, the other to move the code. Sure, that sounds fine. Linus - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
On Sat, 23 Jun 2007 22:02:29 +0100 Al Viro <[EMAIL PROTECTED]> wrote: > On Sat, Jun 23, 2007 at 08:23:43PM +0100, Alan Cox wrote: > > Proc type stuff is a lot older than Linux or Unix AFAIK. Loadable modules > > ditto but the full load/unload/autoload stuff I've not seen pre-Linux. > > Representation of process state and control of that state via files on > a filesystem? I don't know about proc in that sense prior to v8 unix I was thinking about the logical device stuff and filesystem objects/namepaces that produced program generated data. - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
On Sat, Jun 23, 2007 at 04:46:08PM +0100, Alan Cox wrote: > Now if you want really innovative OS work go look in the lab or at > projects most people have never heard of and don't run. Hey, I heard of one. I got a few friends that are sitting in an IRC channel and have been working on a complete new OS from scratch for like 10 years now (kernel, filesystem, graphics drivers, libraries - everything). I consider them to be totally nuts of course. When I ask them why are you still doing this? Can't you use linux? Then the answer is that there are still companies interested in operating systems like that, precisely because they are not well- known. It would be pretty hard to exploit vulnerabilities in such a system (or that is their explanation anyway). -- Carlo Wood <[EMAIL PROTECTED]> - 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 read the FAQ at http://www.tux.org/lkml/
[PATCH] ALSA: more section mismatches
From: Randy Dunlap <[EMAIL PROTECTED]>
Something about __init_or_module isn't working as expected (?).
CONFIG_HOTPLUG=y
CONFIG_MODULES=n
Fix shared init/exit code helper:
WARNING: sound/built-in.o(.exit.text+0x243): Section mismatch: reference to
.init.text: (between 'alsa_card_mpu401_exit' and 'ac97_bus_exit')
WARNING: sound/built-in.o(.exit.text+0x21b): Section mismatch: reference to
.init.text: (between 'alsa_card_dummy_exit' and 'alsa_card_serial_exit')
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
sound/drivers/dummy.c |2 +-
sound/drivers/mpu401/mpu401.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.22-rc5-git8.orig/sound/drivers/mpu401/mpu401.c
+++ linux-2.6.22-rc5-git8/sound/drivers/mpu401/mpu401.c
@@ -228,7 +228,7 @@ static struct pnp_driver snd_mpu401_pnp_
static struct pnp_driver snd_mpu401_pnp_driver;
#endif
-static void __init_or_module snd_mpu401_unregister_all(void)
+static void snd_mpu401_unregister_all(void)
{
int i;
--- linux-2.6.22-rc5-git8.orig/sound/drivers/dummy.c
+++ linux-2.6.22-rc5-git8/sound/drivers/dummy.c
@@ -659,7 +659,7 @@ static struct platform_driver snd_dummy_
},
};
-static void __init_or_module snd_dummy_unregister_all(void)
+static void snd_dummy_unregister_all(void)
{
int i;
-
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 read the FAQ at http://www.tux.org/lkml/
[PATCH] ALSA: fix section mismatch
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix shared init/exit function attributes:
WARNING: sound/built-in.o(.exit.text+0x4a1): Section mismatch: reference to
.init.text: (between 'alsa_card_virmidi_exit' and 'alsa_card_serial_exit')
WARNING: sound/built-in.o(.exit.text+0x4c1): Section mismatch: reference to
.init.text: (between 'alsa_card_serial_exit' and 'ac97_bus_exit')
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
sound/drivers/serial-u16550.c |2 +-
sound/drivers/virmidi.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.22-rc5-git8.orig/sound/drivers/serial-u16550.c
+++ linux-2.6.22-rc5-git8/sound/drivers/serial-u16550.c
@@ -998,7 +998,7 @@ static struct platform_driver snd_serial
},
};
-static void __init_or_module snd_serial_unregister_all(void)
+static void snd_serial_unregister_all(void)
{
int i;
--- linux-2.6.22-rc5-git8.orig/sound/drivers/virmidi.c
+++ linux-2.6.22-rc5-git8/sound/drivers/virmidi.c
@@ -145,7 +145,7 @@ static struct platform_driver snd_virmid
},
};
-static void __init_or_module snd_virmidi_unregister_all(void)
+static void snd_virmidi_unregister_all(void)
{
int i;
-
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 read the FAQ at http://www.tux.org/lkml/
[PATCH] ALSA: use __devexit_p
From: Randy Dunlap <[EMAIL PROTECTED]>
Change __devexit to __devexit_p:
sound/isa/opl3sa2.c:956: error: expected expression before '__attribute__'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
sound/isa/opl3sa2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.22-rc5-git8.orig/sound/isa/opl3sa2.c
+++ linux-2.6.22-rc5-git8/sound/isa/opl3sa2.c
@@ -953,7 +953,7 @@ static int snd_opl3sa2_isa_resume(struct
static struct isa_driver snd_opl3sa2_isa_driver = {
.match = snd_opl3sa2_isa_match,
.probe = snd_opl3sa2_isa_probe,
- .remove = __devexit( snd_opl3sa2_isa_remove),
+ .remove = __devexit_p(snd_opl3sa2_isa_remove),
#ifdef CONFIG_PM
.suspend= snd_opl3sa2_isa_suspend,
.resume = snd_opl3sa2_isa_resume,
-
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 read the FAQ at http://www.tux.org/lkml/
Re: [patch -mm 26/28] x86-64 block irq balancing for timer
On Sat, 2007-06-23 at 13:32 +, Thomas Gleixner wrote: > plain text document attachment > (x86-64-clockevents-irq-balancing.patch) > From: Venki Pallipadi <[EMAIL PROTECTED]> > > Disable irq balancing on IRQ0. this patch is missing some rationale -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] fbdev: make fb_find_mode look for a mode with the highest refresh rate
On Sat, Jun 23, 2007 at 11:04:24AM -0700, Andrew Morton wrote:
> On Sat, 23 Jun 2007 12:50:46 +0200 Michal Januszewski <[EMAIL PROTECTED]>
> wrote:
>
> > + if (!refresh_specified)
> > + refresh = 200;
> > diff = refresh;
> > best = -1;
> > for (i = 0; i < dbsize; i++) {
> > if (name_matches(db[i], name, namelen) ||
> > (res_specified && res_matches(db[i], xres, yres))) {
> > if(!fb_try_mode(var, info, &db[i], bpp)) {
> > - if(!refresh_specified || db[i].refresh ==
> > refresh)
> > + if (refresh_specified && db[i].refresh ==
> > refresh)
> > return 1;
> > else {
> > - if(diff > abs(db[i].refresh - refresh))
> > {
> > + if (diff > abs(db[i].refresh -
> > refresh)) {
> > diff = abs(db[i].refresh -
> > refresh);
> > best = i;
> > }
> > @@ -938,6 +940,7 @@ void fb_destroy_modelist(struct list_head *head)
> > kfree(pos);
> > }
> > }
> > +EXPORT_SYMBOL_GPL(fb_destroy_modelist);
> >
>
> fbdev ignoramus asks: isn't this pretty risky? People who were previously
> relying upon (or at least using) the kernel's default resolution will find
> their displays coming up in a quite different resolution.
The resolution will be unchanged (this part of the code is only executed
if either the name of the mode or the resolution are a match).
What can change is the refresh rate -- it can be set higher than what it
used to be before. But since we're checking all modes with fb_try_mode(),
(which calls fb_check_var()), I think that this change should be safe.
To avoid any side effects we could also do the following:
for (i = 0; i < dbsize; i++) {
if (name_matches(db[i], name, namelen) ||
(res_specified && res_matches(db[i], xres, yres))) {
if(!fb_try_mode(var, info, &db[i], bpp)) {
if (refresh_specified && db[i].refresh ==
refresh)
return 1;
else {
if (diff > abs(db[i].refresh -
refresh)) {
diff = abs(db[i].refresh -
refresh);
best = i;
}
}
}
}
}
if (best != -1) {
fb_try_mode(var, info, &db[best], bpp);
- return 2;
+ return (refresh_specified) ? 2 : 1;
}
which would ensure that 1 is returned if the refresh rate is not
explicitly specified, just as it is done currently:
if(!refresh_specified || db[i].refresh ==
refresh)
return 1
I might be missing something here, so it would be nice if someone
involved in the fb development could comment on the proposed change.
> This change seems to be quite unrelated to the uvesafb stuff and should be
> in a separate patch from the export, which _is_ uvesafb-related. I think.
> If that's wrong then the changelog could do with some attention.
You're right, I'll split this into two patches in the next round.
Best regards,
Michal
-
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 read the FAQ at http://www.tux.org/lkml/
[PATCH] PM: Reduce code duplication between main.c and user.c
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
The SNAPSHOT_S2RAM ioctl code is outdated and it should not duplicate the
suspend code in kernel/power/main.c. Fix that.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
kernel/power/main.c | 89 ---
kernel/power/power.h |3 +
kernel/power/user.c | 38 ++---
3 files changed, 57 insertions(+), 73 deletions(-)
Index: linux-2.6.22-rc5/kernel/power/main.c
===
--- linux-2.6.22-rc5.orig/kernel/power/main.c 2007-06-20 23:17:01.0
+0200
+++ linux-2.6.22-rc5/kernel/power/main.c2007-06-23 19:40:41.0
+0200
@@ -69,14 +69,11 @@ static inline void pm_finish(suspend_sta
/**
* suspend_prepare - Do prep work before entering low-power state.
- * @state: State we're entering.
*
- * This is common code that is called for each state that we're
- * entering. Allocate a console, stop all processes, then make sure
- * the platform can enter the requested state.
+ * This is common code that is called for each state that we're entering.
+ * Run suspend notifiers, allocate a console and stop all processes.
*/
-
-static int suspend_prepare(suspend_state_t state)
+static int suspend_prepare(void)
{
int error;
unsigned int free_pages;
@@ -95,38 +92,18 @@ static int suspend_prepare(suspend_state
goto Thaw;
}
- if ((free_pages = global_page_state(NR_FREE_PAGES))
- < FREE_PAGE_NUMBER) {
+ free_pages = global_page_state(NR_FREE_PAGES);
+ if (free_pages < FREE_PAGE_NUMBER) {
pr_debug("PM: free some memory\n");
shrink_all_memory(FREE_PAGE_NUMBER - free_pages);
if (nr_free_pages() < FREE_PAGE_NUMBER) {
error = -ENOMEM;
printk(KERN_ERR "PM: No enough memory\n");
- goto Thaw;
}
}
-
- suspend_console();
- error = device_suspend(PMSG_SUSPEND);
- if (error) {
- printk(KERN_ERR "Some devices failed to suspend\n");
- goto Resume_console;
- }
- if (pm_ops->prepare) {
- if ((error = pm_ops->prepare(state)))
- goto Resume_devices;
- }
-
- error = disable_nonboot_cpus();
if (!error)
return 0;
- enable_nonboot_cpus();
- pm_finish(state);
- Resume_devices:
- device_resume();
- Resume_console:
- resume_console();
Thaw:
thaw_processes();
pm_restore_console();
@@ -147,6 +124,12 @@ void __attribute__ ((weak)) arch_suspend
local_irq_enable();
}
+/**
+ * suspend_enter - enter the desired system sleep state.
+ * @state: state to enter
+ *
+ * This function should be called after devices have been suspended.
+ */
int suspend_enter(suspend_state_t state)
{
int error = 0;
@@ -166,21 +149,50 @@ int suspend_enter(suspend_state_t state)
return error;
}
+/**
+ * suspend_devices_and_enter - suspend devices and enter the desired
system sleep
+ * state.
+ * @state: state to enter
+ */
+int suspend_devices_and_enter(suspend_state_t state)
+{
+ int error;
+
+ if (!pm_ops)
+ return -ENOSYS;
+
+ suspend_console();
+ error = device_suspend(PMSG_SUSPEND);
+ if (error) {
+ printk(KERN_ERR "Some devices failed to suspend\n");
+ goto Resume_console;
+ }
+ if (pm_ops->prepare) {
+ error = pm_ops->prepare(state);
+ if (error)
+ goto Resume_devices;
+ }
+ error = disable_nonboot_cpus();
+ if (!error)
+ suspend_enter(state);
+
+ enable_nonboot_cpus();
+ pm_finish(state);
+ Resume_devices:
+ device_resume();
+ Resume_console:
+ resume_console();
+ return error;
+}
/**
* suspend_finish - Do final work before exiting suspend sequence.
- * @state: State we're coming out of.
*
* Call platform code to clean up, restart processes, and free the
* console that we've allocated. This is not called for suspend-to-disk.
*/
-
-static void suspend_finish(suspend_state_t state)
+static void suspend_finish(void)
{
- enable_nonboot_cpus();
- pm_finish(state);
- device_resume();
- resume_console();
thaw_processes();
pm_restore_console();
pm_notifier_call_chain(PM_POST_SUSPEND);
@@ -215,7 +227,6 @@ static inline int valid_state(suspend_st
* Then, do the setup for suspend, enter the state, and cleaup (after
* we've woken up).
*/
-
static int enter_state(suspend_state_t state)
{
int error;
@@ -226,14 +237,14 @@ static
Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Adrian Bunk wrote: On Sat, Jun 23, 2007 at 10:56:45AM -0700, Andrew Morton wrote: On Sat, 23 Jun 2007 10:43:03 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: NAK. Sorry I slept thru another wonderful festival on LKML. That's probably the best strategy. You don't have the authority to NAK the patch. Yeah. nak to naks. OTOH, you also didn't supply a patch. If you do this, I'll be glad to consider it. If I can read it, that is. Yes, I plan on merging that patch as-is. If it was a compulsory part of kbuild then that would be a problem but as some optional tool I don't think that a bashism matters much. Someone can fix it sometime should they feel so motivated. Oleg didn't express it very polite, but he has a valid point that bash scripts should start with "#!/bin/bash" since /bin/sh might be some shell other than bash. Randy, am I right to assume that such a change to your patch would be OK? Sure. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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 read the FAQ at http://www.tux.org/lkml/
Re: Linux on XScale 270
Am Samstag 23 Juni 2007 schrieb Dmitry Krivoschekov: > Wolfgang Draxinger wrote: > > Typing "Linux XScale 270 or 27x" brings you a lot of pages but not an > > Probably "XScale 270" is not the best word combination for this, > the exact processor name is PXA270 (formerly Intel, now Marvell). > > > in depth doc/HOWTO how to compile your own kernel and make a boot > > image for that arch. The vendor from which I get the XScale sponsored > > has ready to use Linux images and source on his webpage, but they're > > kinda old and dusty. > > http://www.toradex.ch/colibri_downloads/Linux/ > > > > So what are the steps I've to take, to get a Linux Kernel on a XScale? > > Assuming the mainline kernel already includes support for your machine, It doesn't. I'm currently working on board support for the Toradex Colibri module, plus one board that uses that module. It works for me now, but still needs some testing and cleanup. I'll probably post my patch to the linux-arm-kernel list next week and try to get it into mainline. > > 1. get the latest stable Linux kernel Yes - please _don't_ use the 2.6.12-something stuff available somewhere for the Colibri. It contains a serious bug that cost me days to find, and it's hopelessly out of date. Step 1.1: Apply my board support patch. Either wait until I post it to the list or contact me by private mail. Step 1.2: If your board has an LCD or other extra hardware, add support for it in colibri.c. > 2. compile the kernel: > make ARCH=arm CROSS_COMPILE= > _defconfig > make > > For example, to compile the kernel for Mainstone platform > with blob flashed, do the following: > > make ARCH=arm CROSS_COMPILE=arm-linux- mainstone_defconfig > make zImage Depending on your bootloader, you might need to perform extra steps, e.g. for U-Boot you need to convert zImage to uImage. > > 3. boot the image as appropriate for your bootloader > > > It's obvious that I need a cross compiler for ARM, bootloader images > > and so on, but it's the gory details I'm curios about. > > > > Links to HOWTOs, documentation highly appreciated. And probably > > there's also a better suited maillist than LKML for this, to a > > pointer to that (if existing) would be nice, too. I'd recommend to ask this question again on the linux-arm-kernel list. We shouldn't flood linux-kernel list with arch specific stuff. It would also be interesting to know which toolchain and/or distribution you intend to use. Note that you do not only need a kernel, but also a root file system. The colibri module has only 32MB flash, which means you have to handcraft a small rfs. If you don't have any plans yet, have a look at www.busybox.net, and www.scratchbox.org. I used scratchbox to cross compile my kernel and the packages for my root file system. > > [EMAIL PROTECTED] - for kernel-specific issues > [EMAIL PROTECTED] - for general questions > > these are the most appropriate lists for your questions > (your subscription is required). True. See you there, Hans - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
On Sat, Jun 23, 2007 at 08:23:43PM +0100, Alan Cox wrote: > Proc type stuff is a lot older than Linux or Unix AFAIK. Loadable modules > ditto but the full load/unload/autoload stuff I've not seen pre-Linux. Representation of process state and control of that state via files on a filesystem? AFAIK, it's 80s stuff and at least one of the sources had been research branch in Bell Labs - whether you call it Unix or not... Do you have any references for that animal in earlier systems? A lot older than Unix would mean 50s or 60s... - 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 read the FAQ at http://www.tux.org/lkml/
Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
On Sat, Jun 23, 2007 at 10:56:45AM -0700, Andrew Morton wrote: > On Sat, 23 Jun 2007 10:43:03 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > > NAK. > > > > Sorry I slept thru another wonderful festival on LKML. > > That's probably the best strategy. > > > You don't have the authority to NAK the patch. > > Yeah. nak to naks. > > > OTOH, you also didn't supply a patch. If you do this, I'll be > > glad to consider it. If I can read it, that is. > > Yes, I plan on merging that patch as-is. If it was a compulsory part of > kbuild then that would be a problem but as some optional tool I don't think > that a bashism matters much. Someone can fix it sometime should they feel > so motivated. Oleg didn't express it very polite, but he has a valid point that bash scripts should start with "#!/bin/bash" since /bin/sh might be some shell other than bash. Randy, am I right to assume that such a change to your patch would be OK? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 read the FAQ at http://www.tux.org/lkml/
Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
Hi, On Sat, 23 Jun 2007 10:43:03 -0700, Randy Dunlap wrote: > OTOH, you also didn't supply a patch. If you do this, I'll be glad to > consider it. If I can read it, that is. "s|/bin/sh|/bin/bash" is so hard to do ? Matthieu PS : this remind me http://www.landley.net/code/firmware/ . Is it so difficult to understand that sh is not bash. It is like assuming that everybody as a "qwerty" keyboard. - 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 read the FAQ at http://www.tux.org/lkml/
Re: Linux on XScale 270
Wolfgang Draxinger wrote: > Typing "Linux XScale 270 or 27x" brings you a lot of pages but not an Probably "XScale 270" is not the best word combination for this, the exact processor name is PXA270 (formerly Intel, now Marvell). > in depth doc/HOWTO how to compile your own kernel and make a boot > image for that arch. The vendor from which I get the XScale sponsored > has ready to use Linux images and source on his webpage, but they're > kinda old and dusty. > http://www.toradex.ch/colibri_downloads/Linux/ > > So what are the steps I've to take, to get a Linux Kernel on a XScale? Assuming the mainline kernel already includes support for your machine, 1. get the latest stable Linux kernel 2. compile the kernel: make ARCH=arm CROSS_COMPILE= _defconfig make For example, to compile the kernel for Mainstone platform with blob flashed, do the following: make ARCH=arm CROSS_COMPILE=arm-linux- mainstone_defconfig make zImage 3. boot the image as appropriate for your bootloader > > It's obvious that I need a cross compiler for ARM, bootloader images > and so on, but it's the gory details I'm curios about. > > Links to HOWTOs, documentation highly appreciated. And probably > there's also a better suited maillist than LKML for this, to a > pointer to that (if existing) would be nice, too. > [EMAIL PROTECTED] - for kernel-specific issues [EMAIL PROTECTED] - for general questions these are the most appropriate lists for your questions (your subscription is required). Regards, Dmitry - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] fbdev: add connector entries for uvesafb
On Sat, Jun 23, 2007 at 11:06:27AM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: > On Sat, 23 Jun 2007 12:51:46 +0200 Michal Januszewski <[EMAIL PROTECTED]> > wrote: > > > Add connector's idx and val constants for v86d and uvesafb. > > > > Also change the maximum message size to 4k to allow transfers of VBE > > data blocks from userspace. > > > > Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> > > --- > > include/linux/connector.h |7 --- > > 1 files changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/connector.h b/include/linux/connector.h > > index 10eb56b..46b2aba 100644 > > --- a/include/linux/connector.h > > +++ b/include/linux/connector.h > > @@ -36,14 +36,15 @@ > > #define CN_VAL_CIFS 0x1 > > #define CN_W1_IDX 0x3 /* w1 communication */ > > #define CN_W1_VAL 0x1 > > +#define CN_IDX_V86D0x4 > > +#define CN_VAL_V86D_UVESAFB0x1 > > > > - > > -#define CN_NETLINK_USERS 4 > > +#define CN_NETLINK_USERS 5 > > > > /* > > * Maximum connector's message size. > > */ > > -#define CONNECTOR_MAX_MSG_SIZE 1024 > > +#define CONNECTOR_MAX_MSG_SIZE 4096 > > > > /* > > * idx and val are unique identifiers which > > > > > > Evgeniy, could you please review this? > > The need to add these enumerations for unrelated subsystems to connector.h > may get a bit ugly as time passes, but I guess it's OK for now. Hi. I have no problem with the patch, although it could be possible to split patch to two - add id and increase the size, but it is too minor nit. Ack. -- Evgeniy Polyakov - 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues
On Sat, 23 Jun 2007 15:27:49 -0400 Steven Rostedt <[EMAIL PROTECTED]> wrote: > On Sat, 2007-06-23 at 11:19 -0700, Linus Torvalds wrote: > > > > On Sat, 23 Jun 2007, Andrew Morton wrote: > > > > > > Anyway. Please fix the many correct warnings which checkpatch.pl > > > generates > > > > Actually, please don't. > > You sure? If I were to do this recommended fix, I would simply add > another patch. One to do the fixes, the other to move the code. That way > it should be trivial for something like git to recognize the code > movement, since the code movement patch would be just that, move code, > nothing else. The clean up would be a separate change. > If it's just code movement (I missed that fact) then I'd leave it be: mucking with whitespace and stuff is unrelated to this work. - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
> >- hotplugging > > Was not Windows 95 first here? Hotplug for specialised systems at least is 1950's - 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues
On Sat, 2007-06-23 at 11:19 -0700, Linus Torvalds wrote: > > On Sat, 23 Jun 2007, Andrew Morton wrote: > > > > Anyway. Please fix the many correct warnings which checkpatch.pl > > generates > > Actually, please don't. You sure? If I were to do this recommended fix, I would simply add another patch. One to do the fixes, the other to move the code. That way it should be trivial for something like git to recognize the code movement, since the code movement patch would be just that, move code, nothing else. The clean up would be a separate change. -- Steve - 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues
On Sat, 23 Jun 2007, Randy Dunlap wrote: > > > > Quite frankly, I personally am considering removing "checkpatch.pl". That > > thing is just a nazi dream. That hard-coded 80-character limit etc is just > > bad taste. > > Who wrote that part of CodingStyle? I don't think that the notion of "80 characters per line" is *wrong* per se. So don't take this the wrong way - I think the goal really _should_ be that a function fits on a vt100 terminal window (*both* ways: less than 24 lines of code, and less than 80 characters wide). So I think the notion of trying to keep lines below 80 characters is admirable. That part isn't the problem. The problem is when "coding style guidelines" become "hard inviolate rules". Yes, code should be less than 80 characters wide. But hey, sometimes it's just more readable to have one line that is slightly longer than it should be, than to split something that is awkward to split. The thing that scripts (and computers) have a really hard time with is "judgement". So I don't disagree with any of the checkpatch.pl things individually, but I do disagree with the notion that we should enforce strict rules, when all the guidelines are really just guidelines. For example, the coding style also says that you should avoid indentation that is more than tree deep. It's _true_, but does that mean that we should make deeply indented code *illegal*? Obviously not. It's a "please try to split your functions up" kind of thing. Not a hard rule. The only reason I picked the 80-character thing in particular is that I've seen a fair number of patches that don't do anything *but* change that, and quite often I think it makes the code look worse if it's not done judiciously.. There are other things we really *could* be strict against. For example, the "space followed by tab" thing really is somethign where a strict rule (at least for C files) probably really *is* a good idea, because there really is never a really good reason for it. Add the fact that the problem is "invisible" in most editors, and having a script that checks for it makes even more sense. So I'm happy with checkpatch.pl as a *guide*, but I'm not happy if it means that people start taking it as a *requirement*. (And then I'm doubly unhappy when there are issues like code movement and file renames etc, where there are other reasons why we actually want to keep the code as unmodified as possible). Linus - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] audit: fix oops removing watch if audit disabled
On Sat, 23 Jun 2007 20:16:09 +0100 Al Viro <[EMAIL PROTECTED]> wrote: > On Sat, Jun 23, 2007 at 09:51:53AM -0700, Andrew Morton wrote: > > This looks like 2.6.22 material to me. > > > > Question is: is it also 2.6.21.x material? > > Yes, it is. OK, thanks, I queued it for both kernels. - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
On Sat, 23 Jun 2007 18:19:43 +0200 Grozdan Nikolov <[EMAIL PROTECTED]> wrote: > On Saturday 23 June 2007 18:12, you wrote: > > On Saturday 23 June 2007, Alan Cox wrote: > > > A few innovations that afaik first appeared the Linux kernel > > > - Making multiple hosts appear transparently as one IP address > > > - Futex fast hybrid locking > > > - Single pass checksum fragment and send fragments in reverse order > > > - Reiserfs - very innovative design, but innovation isn't neccessarily > > > success > > > - JFFS/JFFS2 - flash wear levelled file system avoiding all the problem > > > patents > > > - Loadable modules for a non-microkernel > > > > - ALSA framework and drivers > > - Direct Rendering Infrastructure DRI is based on SGI work and Mark Kilgard and the SGI folks definitely did the real visionary work in that area. > > - hotplugging > > > > hmm, wasn't loadable kernel modules first implemented in SunOS 4.x together > with the proc system ? Proc type stuff is a lot older than Linux or Unix AFAIK. Loadable modules ditto but the full load/unload/autoload stuff I've not seen pre-Linux. - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] audit: fix oops removing watch if audit disabled
On Sat, Jun 23, 2007 at 09:51:53AM -0700, Andrew Morton wrote: > This looks like 2.6.22 material to me. > > Question is: is it also 2.6.21.x material? Yes, it is. - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][AGPGART] intel_agp: don't load if no IGD and AGP port
On Sat, Jun 23, 2007 at 11:50:49AM -0700, Andrew Morton wrote: > On Sat, 23 Jun 2007 14:42:21 -0400 Dave Jones <[EMAIL PROTECTED]> wrote: > > > > I probably _could_ work this out, and kinda did with a bit of > > list-trolling > > > (verdict: needed in 2.6.22) but please, take care to describe the > > > importance of a patch in the changelog? > > > > This got merged a day or two ago. > > OK. -stable didn't appear to get a copy though? Correct. It'll need a slightly different fix due to the cleanups done in .22rc I also wanted it to sit for a few days to make sure there aren't any other nasties lurking that this churn has unearthed. Dave -- http://www.codemonkey.org.uk - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
On Saturday 23 June 2007 20:54, you wrote: > Grozdan Nikolov wrote: > > On Saturday 23 June 2007 19:53, you wrote: > >> On Sat, 2007-06-23 at 14:17 +0200, Grozdan Nikolov wrote: > >> [...] > >> > >>> Please CC me as I'm not subscribe to this mailing list, > >> > >> Perhaps you should change that and find most answers for yourself. > >> > >>> Thanks! > >> > >> Thanks! > >> > >>Bernd > > > > Perhaps you should change your rude attitude towards people who are > > seeking for answers without actually looking for rants or flame-wars. If > > you have read my replies to Alan, you should know why I asked these > > questions To clarify something that might be incorrect or biased in > > the articles I've read so far... if you could tell me a better place to > > ask about Linux internal stuff, please tell me so.. > > well, i would say this - put yourself into the shoes of a kernel > developer who barely has time to keep track of the large volume of > development work, discussions, testing, etc. Then someone who claims to > be not a kernel developer, who isn't subscribed to the list comes along > and says 'there is _no_ innovation in the linux kernel'. What would your > reaction be? My reaction will be to clarify it to this person that this is not true (and thanks to the some of you who already did), even if I'm under pressure from development work/testing/patching... But this is just the type of person I am. Everyone is different so I expected some "rude" reactions. But there are people who are willing to clarify things (Alan Cox, Jeffrey Merkey, Diego Calleja on the clarification of dtrace being used on OS/2, etc). Many thanks to those... If some of you get annoyed (which is perfectly possible), then just don't bother getting involved in this thread :) > > I'm not a kernel developer myself, but i think there are lots of > resources on the internet where you can read watered down versions of > discussions happening on this list. If there are I'm unaware of those, thanks for the hint though > > > willing to answer or clarify some things to a person who's just looking > > for the *correct* answers > > Of course, everyone wants to learn from the gurus. But confronting them > in this way hardly seems the right way ;) > > -jb - 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues
On Sat, 23 Jun 2007 11:52:52 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: > > Quite frankly, I personally am considering removing "checkpatch.pl". That > > thing is just a nazi dream. That hard-coded 80-character limit etc is just > > bad taste. > > Who wrote that part of CodingStyle? > > > The script is certainly no substitute for personal review. > And it's certainly not the final say on anything. > (neither is CodingStyle AFAIK) > It's just a helper for Andrew. people are free to disagree with it - it's more of a "hey, did you really mean to do this" thing. It might need some fine-tuning.. - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
Grozdan Nikolov wrote: > On Saturday 23 June 2007 19:53, you wrote: >> On Sat, 2007-06-23 at 14:17 +0200, Grozdan Nikolov wrote: >> [...] >> >>> Please CC me as I'm not subscribe to this mailing list, >> Perhaps you should change that and find most answers for yourself. >> >>> Thanks! >> Thanks! >> >> Bernd > > Perhaps you should change your rude attitude towards people who are seeking > for answers without actually looking for rants or flame-wars. If you have > read my replies to Alan, you should know why I asked these questions To > clarify something that might be incorrect or biased in the articles I've read > so far... if you could tell me a better place to ask about Linux internal > stuff, please tell me so.. > well, i would say this - put yourself into the shoes of a kernel developer who barely has time to keep track of the large volume of development work, discussions, testing, etc. Then someone who claims to be not a kernel developer, who isn't subscribed to the list comes along and says 'there is _no_ innovation in the linux kernel'. What would your reaction be? I'm not a kernel developer myself, but i think there are lots of resources on the internet where you can read watered down versions of discussions happening on this list. > willing to answer or clarify some things to a person who's just looking for > the *correct* answers > Of course, everyone wants to learn from the gurus. But confronting them in this way hardly seems the right way ;) -jb -- Tact is the art of making a point without making an enemy. - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][AGPGART] intel_agp: don't load if no IGD and AGP port
On Sat, 23 Jun 2007 14:42:21 -0400 Dave Jones <[EMAIL PROTECTED]> wrote: > > I probably _could_ work this out, and kinda did with a bit of list-trolling > > (verdict: needed in 2.6.22) but please, take care to describe the > > importance of a patch in the changelog? > > This got merged a day or two ago. OK. -stable didn't appear to get a copy though? - 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues
On Sat, 23 Jun 2007 11:19:18 -0700 (PDT) Linus Torvalds wrote: > > > On Sat, 23 Jun 2007, Andrew Morton wrote: > > > > Anyway. Please fix the many correct warnings which checkpatch.pl > > generates > > Actually, please don't. > > Especially for code movement, *just* do the movement. Screw any > checkpatch.pl crap - the code is better off not changing, because that way > a big patch can not only be proven to not change anything at all, but > software archeology tools can trivially find the true history of the code > over code movement. > > For example, "git blame -C" already finds copies and can annotate the > history of a line of code past a pure code movement. But if you move *and* > change things at the same time, it gets a lot harder to show where the > code came from and that the movement itself caused no regressions. > > So do cleanups _separately_ from movement. > > (Yeah, yeah, "git blame -C -w" will generally work across whitespace > changes too, but only whitespace _within_ a line. If you do things like > split long lines etc, you immediately have a lot harder time to follow > these thigns. Not impossible, but the point is that you're not *fixing* > anything, you're just making things *worse* by doing changes and code > movement at the same time). > > Quite frankly, I personally am considering removing "checkpatch.pl". That > thing is just a nazi dream. That hard-coded 80-character limit etc is just > bad taste. Who wrote that part of CodingStyle? The script is certainly no substitute for personal review. And it's certainly not the final say on anything. (neither is CodingStyle AFAIK) It's just a helper for Andrew. The problem IMO is that we are seeing less and less patch review but it needs to be more and more. Andrew is one of a handful of people who are reviewing lots of patches. It shouldn't be his wheelbarrow to have to push around all the time. So if a little automation can help Andrew, that's a good thing. Until people revolt, that is. > Dammit, code cleanliness is not about "automated and mindless slavish > following of rules". A process that is too inflexible is a *bad* process. > I'd much rather have a few 80+ character lines than stupid and unreadable > line wrapping just because the line hit 87 characters in length. > > I don't have 25 lines on a screen either. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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 read the FAQ at http://www.tux.org/lkml/
make xconfig failure on 2.6.21.5
Hi, I have a Kubuntu 7.04 distro with Qt4 development packages installed. Trying to do a 'make xconfig' fails with: HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc CHECK qt * * Unable to find the QT installation. Please make sure that * the QT development package is correctly installed and * either install pkg-config or set the QTDIR environment * variable to the correct location. * HOSTCC scripts/kconfig/conf.o sed < scripts/kconfig/lkc_proto.h > scripts/kconfig/lkc_defs.h 's/P(\([^,]*\),.*/#define \1 (\*\1_p)/' HOSTCC scripts/kconfig/kconfig_load.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o make[1]: *** No rule to make target `scripts/kconfig/.tmp_qtcheck', needed by `scripts/kconfig/qconf.o'. Stop. make: *** [xconfig] Error 2 Is this a problem with my setup or that kbuild/kconfig can't handle Qt4? I noticed that scripts/kconfig/Makefile checks for: pkg-config --exists qt pkg-config --exists qt-mt whereas the Qt4 installation I have the *.pc files are: Qt3Support.pc QtCore.pc QtGui.pc and also the places where kconfig checks for qconfig.h doesn't seem to be where Qt4 keeps it (in my installation), /usr/share/qt4/include/QtCore/qconfig.h /usr/share/qt4/include/Qt/qconfig.h Anyone else run into the same problem? -jb -- Tact is the art of making a point without making an enemy. - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][AGPGART] intel_agp: don't load if no IGD and AGP port
On Sat, Jun 23, 2007 at 09:52:03AM -0700, Andrew Morton wrote: > > On Thu, 21 Jun 2007 13:43:18 +0800 Wang Zhenyu <[EMAIL PROTECTED]> wrote: > > Thanks Carlo to report this problem. The following patch should fix > > his and potential issue. > > > > [AGPGART] intel_agp: don't load if no IGD detected and no AGP port > > > > After i915 chip, GMCH has no AGP port. Origin bridge driver in device > > table will try to access illegal regs like APBASE, APSIZE, etc. This > > may cause problem. > > > > So mark them as NULL in the table, we won't load if no IGD got detect > > and bridge has no AGP port. > > Looking at the above, I have no way of telling what the actual bug is, nor > have I any way of telling what the consequences would be of not having this > patch in 2.6.22. Nor can I tell whether we want it in 2.6.21.x. > > I probably _could_ work this out, and kinda did with a bit of list-trolling > (verdict: needed in 2.6.22) but please, take care to describe the > importance of a patch in the changelog? This got merged a day or two ago. "will try to access illegal regs.." being the key part of the changelog above. Without this diff, it goes bang, and stops booting on certain chipsets. Dave -- http://www.codemonkey.org.uk - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
On Saturday 23 June 2007 21:18, you wrote: > There's a lot in Linux that was true innnovation: > > Alan Cox's Networking Architecture. > VFS Architecture (best one out there -- even better than M$'s) > Scheduler Design. > > Jeff Thanks Jeff, so from reading all the responses here I can conclude that Linux innovates stuff by itself and not only gets it from other places. Is it also right to say that other kernels, be it BSD, Solaris, maybe AIX?, also benefit from the Linux innovations? eg adding stuff from the Linux kernel into their own kernels if their licenses allow it - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] fbdev: uvesafb driver
On Sat, 23 Jun 2007 12:52:43 +0200 Michal Januszewski <[EMAIL PROTECTED]> wrote:
> Add the uvesafb driver, an enhanced version of vesafb that makes use of
> a userspace helper to run x86 Video BIOS code.
>
> Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
> ---
> drivers/video/Kconfig | 18 +
> drivers/video/Makefile |1 +
> drivers/video/uvesafb.c | 1902
> +++
> include/video/Kbuild|2 +-
> include/video/uvesafb.h | 208 ++
> 5 files changed, 2130 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 403dac7..5cc03f9 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -585,6 +585,24 @@ config FB_TGA
>
> Say Y if you have one of those.
>
> +config FB_UVESA
> + tristate "Userspace VESA VGA graphics support"
> + depends on FB && CONNECTOR
These dependencies are insufficient.
> ...
>
> --- /dev/null
> +++ b/drivers/video/uvesafb.c
> @@ -0,0 +1,1902 @@
> +/*
> + * A framebuffer driver for VBE 2.0+ compliant video cards
> + *
> + * (c) 2007 Michal Januszewski <[EMAIL PROTECTED]>
> + * Loosely based upon the vesafb driver.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Only x86 has mtrr.h: you just broke allmodconfig on all other
architectures.
> +#include "edid.h"
> +
> +static struct cb_id uvesafb_cn_id = {
> + .idx = CN_IDX_V86D,
> + .val = CN_VAL_V86D_UVESAFB
> +};
> +static struct sock *nls;
> +static char v86d_path[PATH_MAX] = "/sbin/v86d";
Remove the PATH_MAX, save some memory.
Oh, it gets set via sysfs. hrm.
> +static char v86d_started = 0;/* has v86d been started by uvesafb? */
Unneeded initialisation-to-zero.
scripts/checkpatch.pl would have reported this. It in fact generates 93
warnings against this patch and from a quick scan, they all look
legitimate.
> +static void uvesafb_cn_callback(void *data)
> +{
> + struct cn_msg *msg = (struct cn_msg *)data;
unneeded cast of void*
> + struct uvesafb_task *utask = (struct uvesafb_task *)msg->data;
> + struct uvesafb_ktask *task;
> +
> + if (msg->seq >= UVESAFB_TASKS_MAX)
> + return;
> +
> + task = uvfb_tasks[msg->seq];
> +
> + if (!task || msg->ack != task->ack)
> + return;
> +
> + memcpy(&task->t, utask, sizeof(struct uvesafb_task));
> +
> + if (task->t.buf_len && task->buf)
> + memcpy(task->buf, ((u8*)utask) + sizeof(struct uvesafb_task),
> + task->t.buf_len);
Isn't this
memcpy(task->buf, utask + 1, task->t.buf_len);
?
> +
> + complete(task->done);
> + return;
> +}
> +
> +static int uvesafb_helper_start(void)
> +{
> + char *envp[] = {
> + "HOME=/",
> + "PATH=/sbin:/bin",
> + NULL,
> + };
> +
> + char *argv[] = {
> + v86d_path,
> + NULL,
> + };
> +
> + return call_usermodehelper(v86d_path, argv, envp, 1);
> +}
Now I'm wondering what this code actually does. It would be nice to have
an overall design and implementation description in the changelog so we
don't have to reverse-engineer your thoughts from your implementation...
The comment over uvesafb_exec() helps.
> +static struct uvesafb_ktask *uvesafb_prep(void)
> +{
> + struct uvesafb_ktask *task;
> +
> + task = kzalloc(sizeof(struct uvesafb_ktask), GFP_ATOMIC);
> + if (task) {
> + task->done = kzalloc(sizeof(struct completion), GFP_ATOMIC);
> + if (!task->done) {
> + kfree(task);
> + task = NULL;
> + }
> + }
> + return task;
> +}
GFP_ATOMIC is unreliable and should be strenuously avoided. I suspect all
callers can use GFP_KERNEL here. If not, we should at least pass the gfp_t
into this function as an argument so that we can use GFP_KERNEL from as
many callsites as possible.
> +/*
> + * Execute a uvesafb task.
> + *
> + * Returns 0 if the task is executed successfully.
> + *
> + * A message sent to the userspace consists of the uvesafb_task
> + * struct and (optionally) a buffer. The uvesafb_task struct is
> + * a simplified version of uvesafb_ktask (its kernel counterpart)
> + * containing only the register values, flags and the length of
> + * the buffer.
> + *
> + * Each message is assigned a sequence number (increased linearly)
> + * and a random ack number. The sequence number is used as a key
> + * for the uvfb_tasks array which holds pointers to uvesafb_ktask
> + * structs for all requests.
> + */
> +static int uvesafb_exec(struct uvesafb_ktask *task)
> +{
> + static int seq = 0;
> + struct cn_msg *m;
> + int err;
> + int len = sizeof(task->t) + task->t.buf_len;
> +
> + /* Check whether the message isn't
Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues
On Sat, 23 Jun 2007, Andrew Morton wrote: > > Anyway. Please fix the many correct warnings which checkpatch.pl > generates Actually, please don't. Especially for code movement, *just* do the movement. Screw any checkpatch.pl crap - the code is better off not changing, because that way a big patch can not only be proven to not change anything at all, but software archeology tools can trivially find the true history of the code over code movement. For example, "git blame -C" already finds copies and can annotate the history of a line of code past a pure code movement. But if you move *and* change things at the same time, it gets a lot harder to show where the code came from and that the movement itself caused no regressions. So do cleanups _separately_ from movement. (Yeah, yeah, "git blame -C -w" will generally work across whitespace changes too, but only whitespace _within_ a line. If you do things like split long lines etc, you immediately have a lot harder time to follow these thigns. Not impossible, but the point is that you're not *fixing* anything, you're just making things *worse* by doing changes and code movement at the same time). Quite frankly, I personally am considering removing "checkpatch.pl". That thing is just a nazi dream. That hard-coded 80-character limit etc is just bad taste. Dammit, code cleanliness is not about "automated and mindless slavish following of rules". A process that is too inflexible is a *bad* process. I'd much rather have a few 80+ character lines than stupid and unreadable line wrapping just because the line hit 87 characters in length. I don't have 25 lines on a screen either. Linus - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
> > then what is this? Provocation is _standard_ troll tactics. > > Why don't you try being innovative yourself? Because I've seen many times how people outside the kernel community get ignored or even labled as trolls when asking something, so I thought that provocation in this case could be better productive for me. - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
On Saturday 23 June 2007 19:53, you wrote: > On Sat, 2007-06-23 at 14:17 +0200, Grozdan Nikolov wrote: > [...] > > > Please CC me as I'm not subscribe to this mailing list, > > Perhaps you should change that and find most answers for yourself. > > > Thanks! > > Thanks! > > Bernd Perhaps you should change your rude attitude towards people who are seeking for answers without actually looking for rants or flame-wars. If you have read my replies to Alan, you should know why I asked these questions To clarify something that might be incorrect or biased in the articles I've read so far... if you could tell me a better place to ask about Linux internal stuff, please tell me so.. As I'm not a kernel programmer I don't see the need to subscribe to the LKML, I can contribute nothing to it. Yes, I do follow the LKML by reading it (that's how I discovered the new CPU schedulers from Ingo and Con and gave them a try, great piece of software, by the way). Reading kernel "patch e-mails" doesn't really teach you who invented this stuff... there are probably a lot of technologies which I'm not aware of their inventors, hence the simple questions I asked to clarify it for myself.. but if you decide that it's trolling because I'm not part of your "kernel development team" and I don't contribute to it (maybe I don't have the skills?) then you are the one who keeps the biased or wrong articles out there live longer by not willing to answer or clarify some things to a person who's just looking for the *correct* answers Thanks !!! - 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 read the FAQ at http://www.tux.org/lkml/
Linux on XScale 270
Typing "Linux XScale 270 or 27x" brings you a lot of pages but not an in depth doc/HOWTO how to compile your own kernel and make a boot image for that arch. The vendor from which I get the XScale sponsored has ready to use Linux images and source on his webpage, but they're kinda old and dusty. http://www.toradex.ch/colibri_downloads/Linux/ So what are the steps I've to take, to get a Linux Kernel on a XScale? It's obvious that I need a cross compiler for ARM, bootloader images and so on, but it's the gory details I'm curios about. Links to HOWTOs, documentation highly appreciated. And probably there's also a better suited maillist than LKML for this, to a pointer to that (if existing) would be nice, too. Thanks in advance Wolfgang pgpVgYIxJOOYe.pgp Description: PGP signature
Re: How innovative is Linux?
On Jun 23 2007 18:12, Torsten Duwe wrote: >On Saturday 23 June 2007, Alan Cox wrote: > >> A few innovations that afaik first appeared the Linux kernel >> - Making multiple hosts appear transparently as one IP address >> - Futex fast hybrid locking >> - Single pass checksum fragment and send fragments in reverse order >> - Reiserfs - very innovative design, but innovation isn't neccessarily >> success >> - JFFS/JFFS2 - flash wear levelled file system avoiding all the problem >> patents >> - Loadable modules for a non-microkernel > >- hotplugging Was not Windows 95 first here? Jan -- - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] fbdev: add connector entries for uvesafb
On Sat, 23 Jun 2007 12:51:46 +0200 Michal Januszewski <[EMAIL PROTECTED]> wrote: > Add connector's idx and val constants for v86d and uvesafb. > > Also change the maximum message size to 4k to allow transfers of VBE > data blocks from userspace. > > Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]> > --- > include/linux/connector.h |7 --- > 1 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/include/linux/connector.h b/include/linux/connector.h > index 10eb56b..46b2aba 100644 > --- a/include/linux/connector.h > +++ b/include/linux/connector.h > @@ -36,14 +36,15 @@ > #define CN_VAL_CIFS 0x1 > #define CN_W1_IDX0x3 /* w1 communication */ > #define CN_W1_VAL0x1 > +#define CN_IDX_V86D 0x4 > +#define CN_VAL_V86D_UVESAFB 0x1 > > - > -#define CN_NETLINK_USERS 4 > +#define CN_NETLINK_USERS 5 > > /* > * Maximum connector's message size. > */ > -#define CONNECTOR_MAX_MSG_SIZE 1024 > +#define CONNECTOR_MAX_MSG_SIZE 4096 > > /* > * idx and val are unique identifiers which > > Evgeniy, could you please review this? The need to add these enumerations for unrelated subsystems to connector.h may get a bit ugly as time passes, but I guess it's OK for now. - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] fbdev: make fb_find_mode look for a mode with the highest refresh rate
On Sat, 23 Jun 2007 12:50:46 +0200 Michal Januszewski <[EMAIL PROTECTED]> wrote:
> If the refresh rate hasn't been explicitly specified, fd_find_mode
> currently returns the first mode with the requested resolution. Change
> it so that it returns a mode with the requested resolution and the
> highest refresh rate.
>
> Also export fb_destroy_modelist, which is used in uvesafb.
>
> Signed-off-by: Michal Januszewski <[EMAIL PROTECTED]>
> ---
> drivers/video/modedb.c |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
> index 3741ad7..98ee77b 100644
> --- a/drivers/video/modedb.c
> +++ b/drivers/video/modedb.c
> @@ -606,16 +606,18 @@ done:
> DPRINTK("Trying specified video mode%s %ix%i\n",
> refresh_specified ? "" : " (ignoring refresh rate)", xres, yres);
>
> + if (!refresh_specified)
> + refresh = 200;
> diff = refresh;
> best = -1;
> for (i = 0; i < dbsize; i++) {
> if (name_matches(db[i], name, namelen) ||
> (res_specified && res_matches(db[i], xres, yres))) {
> if(!fb_try_mode(var, info, &db[i], bpp)) {
> - if(!refresh_specified || db[i].refresh ==
> refresh)
> + if (refresh_specified && db[i].refresh ==
> refresh)
> return 1;
> else {
> - if(diff > abs(db[i].refresh - refresh))
> {
> + if (diff > abs(db[i].refresh -
> refresh)) {
> diff = abs(db[i].refresh -
> refresh);
> best = i;
> }
> @@ -938,6 +940,7 @@ void fb_destroy_modelist(struct list_head *head)
> kfree(pos);
> }
> }
> +EXPORT_SYMBOL_GPL(fb_destroy_modelist);
>
fbdev ignoramus asks: isn't this pretty risky? People who were previously
relying upon (or at least using) the kernel's default resolution will find
their displays coming up in a quite different resolution.
This change seems to be quite unrelated to the uvesafb stuff and should be
in a separate patch from the export, which _is_ uvesafb-related. I think.
If that's wrong then the changelog could do with some attention.
-
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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/5 v2] Convert tasklets to work queues
On Sat, 2007-06-23 at 09:53 -0700, Andrew Morton wrote:
> > On Fri, 22 Jun 2007 14:20:56 -0400 Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > This patch replaces the tasklet implementation with a work
> > queue implementation while keeping the tasklet API.
> > The API is still the same, and the drivers don't know that a
> > work queue is being used.
>
> I still think this sucks: we end up with a fairly pointless-looking wrapper
> API which we wouldn't have put in the kernel except for messy legacy
> editing-is-too-hard reasons. In an ideal world, it'd be better just to get
> in and do the hard work.
If I had all the hardware that tasklets touch, I'd start doing it. (look
for more patches from me that do this for the hardware I do have :-)
>
> Anyway. Please fix the many correct warnings which checkpatch.pl
I'll have to add a clean up patch. A lot of the output from that came
from me moving existing code. So I'll have to clean up the existing
code first so that checkpatch.pl doesn't complain about it. I prefer a
patch that moves code to do nothing but that, move code and not even add
clean ups to it. So the simple solution is, add patch to clean up (will
do).
Also this:
void tasklet_schedule(struct tasklet_struct *t)
{
WARN_ON_ONCE(!ktaskletd_wq);
queue_work(ktaskletd_wq, &t->work);
}
EXPORT_SYMBOL(tasklet_schedule);
produces
PATCH: tasklets-to-workqueues.patch:259:
FILE: linux-2.6-test/kernel/tasklet_work.c:30:
+EXPORT_SYMBOL(tasklet_schedule);
So I guess that blank line is not acceptable?
and should be:
void tasklet_schedule(struct tasklet_struct *t)
{
WARN_ON_ONCE(!ktaskletd_wq);
queue_work(ktaskletd_wq, &t->work);
}
EXPORT_SYMBOL(tasklet_schedule);
I'll fix that up.
> generates, reissue the patches with a decent overall changelog (this series
> had no rationale for the changes at all) and we'll see what happens.
Should I just put in the prologue from the first series, or slim it down
a bit so people don't need to read the whole thing every time? I can
just put in the stuff that's relevant and leave out the "history".
Thanks,
-- Steve
-
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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
> > Grozdan Nikolov <[EMAIL PROTECTED]> wrote: > > Hello gentlemen and ladies. > > > > As a Linux user for many years now (regulars user, not a programmer), I > > want > > Please do not feed the trolls, thank you Absolutely. We had almost 900+ not-so-productive mails on another thread recently ... On 6/23/07, Grozdan Nikolov <[EMAIL PROTECTED]> wrote: heh, I'm not a troll, Ok, Grozdan, but ... but it seems you all go hiding instead of explaining and making a clear stand then what is this? Provocation is _standard_ troll tactics. Why don't you try being innovative yourself? - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sns: add syscall to check signed state of a process [4/4]
On Jun 21 2007 18:49, Alexander Wuerstlein wrote: > >You seem to be right, the rest of the kernel just does 'if (!t)'. We just used >IS_ERR() as the 'check for evil pointers' function. But NULL is not covered by IS_ERR. Jan -- - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Check files' signatures before doing suid/sgid [2/4]
On Jun 21 2007 19:46, Alexander Wuerstlein wrote: > >If a process uses read() it needs some executable and writable memory. We do >check for this in mprotect(). There is a problem with the i386-architecture, >because it allows execution of any readable page (except with newer >processors). But beyond that ugliness of i386, it should not be possible to >execute anything without us noticing it (hopefully). r and x together is not a problem IMHO. Jan -- - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
There's a lot in Linux that was true innnovation: Alan Cox's Networking Architecture. VFS Architecture (best one out there -- even better than M$'s) Scheduler Design. Jeff - 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 read the FAQ at http://www.tux.org/lkml/
Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
On Sat, 23 Jun 2007 10:43:03 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote: > > NAK. > > Sorry I slept thru another wonderful festival on LKML. That's probably the best strategy. > You don't have the authority to NAK the patch. Yeah. nak to naks. > OTOH, you also didn't supply a patch. If you do this, I'll be > glad to consider it. If I can read it, that is. Yes, I plan on merging that patch as-is. If it was a compulsory part of kbuild then that would be a problem but as some optional tool I don't think that a bashism matters much. Someone can fix it sometime should they feel so motivated. - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
El Sat, 23 Jun 2007 23:00:42 +0530, jimmy bahuleyan <[EMAIL PROTECTED]> escribió: > building upon or improving existing technology is as important as > inventing new things. if every one insisted on dreaming up new things, i > doubt we would've accomplished anything significant (not just in OS, > anywhere ;) Let's also not forget that many of the "innovative" features that Grodzan says Linux has copied to Solaris and other Unixes, were actually not invented by them. OS/2 already had dtrace in 1994 (it even had the same name), and many of the traditional Unix features were copied^Wheavily inspired in multics. - 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Check files' signatures before doing suid/sgid [2/4]
On Jun 22 2007 20:25, Alexander Wuerstlein wrote:
>+#ifdef CONFIG_SNS_SIGNED
>+#include
>+#endif
>
> #include
> #include
>@@ -928,13 +931,21 @@ int prepare_binprm(struct linux_binprm *bprm)
> mode = inode->i_mode;
> if (bprm->file->f_op == NULL)
> return -EACCES;
>+#ifdef CONFIG_SNS_SIGNED
>+ if (mode & S_ISUID)
>+ current->sns_valid_sig = sns_signature_valid(bprm->file);
>+#endif
>
> bprm->e_uid = current->euid;
> bprm->e_gid = current->egid;
>
> if(!(bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)) {
> /* Set-uid? */
>- if (mode & S_ISUID) {
>+#ifdef CONFIG_SNS_SIGNED_SETUID
>+ if (mode & S_ISUID && current->sns_valid_sig) {
>+#else
>+ if (mode & S_ISUID) {
>+#endif /*SNS_SIGNED_SETUID*/
> current->personality &= ~PER_CLEAR_ON_SETID;
> bprm->e_uid = inode->i_uid;
> }
>@@ -945,7 +956,11 @@ int prepare_binprm(struct linux_binprm *bprm)
>* is a candidate for mandatory locking, not a setgid
>* executable.
>*/
>- if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
>+#ifdef CONFIG_SNS_SIGNED_SETGID
>+ if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP) &&
>current->sns_valid_sig) {
>+#else
>+ if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
>+#endif /*SNS_SIGNED_SETGID*/
> current->personality &= ~PER_CLEAR_ON_SETID;
> bprm->e_gid = inode->i_gid;
> }
...
That's a lot of unwanted ifdefs!
Jan
--
-
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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
On Sat, 2007-06-23 at 14:17 +0200, Grozdan Nikolov wrote: [...] > Please CC me as I'm not subscribe to this mailing list, Perhaps you should change that and find most answers for yourself. > Thanks! Thanks! Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - 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 read the FAQ at http://www.tux.org/lkml/
Re: SATA RAID5 speed drop of 100 MB/s
Hi, On Saturday 23 June 2007, Carlo Wood wrote: > PS I'd like to do extensive testing with Bonnie++ to tune everything > there is to tune. But bonnie likes to write/read files TWICE the amount > of RAM I have. It therefore takes a LOT of time to run one test. Do you > happen to know how I can limit the amount of RAM that the linux kernel > sees to, say 500 MB? That should be enough to run in Single User mode > but allow me to run the tests MUCH faster. (I have dual channel, four > DIMM's of 1 GB each -- 2 GB per Core 2 die. Hopefully the fact that > I have dual channel isn't going to be a problem when limiting the ram > that the kernel sees.) "mem=" kernel parameter limits amount of memory seen by kernel (more info in Documentation/kernel-parameters.txt) You can also limit amount of RAM detected by bonnie++ by using -r parameter but please remember that this will make bonnie++ benchmark combined kernel I/O buffering + filesystem + hard disk performance instead of just filesystem + hard disk performance (as it can happen that some / all data won't ever hit the disk). Bart - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
> "AC" == Alan Cox <[EMAIL PROTECTED]> writes: AC> A few innovations that afaik first appeared the Linux kernel The clone() call and the efficient 1:1 threading it brought was definitely innovative. None of the other Unices had anything similar. splice() is innovative as well, even though it took 10 years from concept to implementation... /Benny - 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 read the FAQ at http://www.tux.org/lkml/
Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info
On Sat, 23 Jun 2007 10:34:59 +0200 Oleg Verych wrote: > * From: Randy Dunlap > * Newsgroups: linux.kernel > * Date: Fri, 22 Jun 2007 13:28:10 -0700 > * Organization: Oracle Linux Eng. > > [] > > --- /dev/null > > +++ linux-2.6.22-rc5/scripts/decodecode > > @@ -0,0 +1,47 @@ > > +#!/bin/sh > > +# Disassemble the Code: line in Linux oopses > > +# usage: decodecode < oops.file > > |-*- sh = dash -*- > flower:-$ Jun 18 22:05:11 localhost kernel: Code: 00 00 00 eb 1b 6b 4e 38 05 89 ca 03 > 53 \ > 1c 4a 89 d0 31 d2 f7 f1 89 da 89 c1 89 f0 e8 83 ed ff ff e8 26 af 12 00 8b 76 > 6\ > 4 83 ee 64 <8b> 46 64 0f 18 00 90 81 fe 14 5c 37 c0 0f 85 70 ff ff ff b8 84 > decodecode: 31: Syntax error: Bad substitution > flower:-$ > |-*- > > Or you are writing for "#!/bin/bash", or i can help optimize and make > this script "sh" compatible. > > NAK. Sorry I slept thru another wonderful festival on LKML. You don't have the authority to NAK the patch. OTOH, you also didn't supply a patch. If you do this, I'll be glad to consider it. If I can read it, that is. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
Alan Cox wrote: > > I'd argue the lack of a stable kernel internal API is also an innovation > Give me a break Alan; you are smarter than that! Arguing the validity of a stable Kernel internal API is as ridiculous as arguing the validity of the paperclip. The paperclip allows you to attach things to each other, no matter which version of paper you use. Please wake up! Thanks! -- Al - 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 read the FAQ at http://www.tux.org/lkml/
Re: Question about fair schedulers
El Saturday 23 June 2007 18:35:18 Kyle Moffett escribió: > If you want the kernel to > treat one job or the other as more important then you must *TELL* it > that, end of story. Yes, that makes sense now that it's been explained to me conveniently. As long as a normal user is not left alone with such task (as it won't happen), I'm more than happy with the solution. > > Yes, I see your point. In a scenario of dropping frames it seems > > that CFS does a better job. It's just that an ideal scheduler > > shouldn't drop frames in this case (it should give 70% to the video > > even without nicing the encoder). > > It can't do that. The with-CFS kernel just sees 2 CPU-heavy > processes and guesses that it should give them equal CPU. "stock" > kernels have an algorithm designed to promote some tasks for > "interactivity", but in practice it also tended to cause other > processes to be denied CPU for arbitrarily long periods of time, > hence why CFS is an improvement. Under the old scheduler even if you > had 2 DVD player processes each chewing 45% CPU, you could still have > dropped frames because for a second or two one would be more > "interactive" than the other, and vice versa. Under CFS/SD, they are > both classified equally and so get equal CPU allocation *AND* latency. This adds even more sense to all the explanations I've heard up to now. Thanks :) > I don't see any reason someone couldn't write a simple little GUI > program to enumerate the user-owned X processes (somewhat like the > Windows Task-Manager but less complicated) and allow them to change > priorities. Alternatively your desktop environment could set up a > little privileged wrapper which appropriately executes the HD video > player. One of the primary rules of kernel development is that you > cannot put policy in the kernel, and a statement of the form > "PROCESS1 is more important than PROCESS2" is pure policy and must be > done from userspace. We even give appropriate enforcement mechanisms > to userspace to take such action (nice levels). Yes, an app to change priorities would be very nice, though I'd be happy with just sensible defaults. Probably once CFS or SD go mainline more application developers will make their apps run at the appropriate nice level (or else distributions will provide this when packaging the apps), so end users won't have any problems. > Cheers, > Kyle Moffett Thank you, Alberto. - 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 read the FAQ at http://www.tux.org/lkml/
Re: How innovative is Linux?
Torsten Duwe wrote: > On Saturday 23 June 2007, you wrote: > >> hmm, wasn't loadable kernel modules first implemented in SunOS 4.x [...] > Yes, but that was pretty cumbersome. You had to resolve the symbols in user > space, using a hopefully matching /vmunix. Linux was first to feature an > in-kernel linker and symbol table, IIRC. > building upon or improving existing technology is as important as inventing new things. if every one insisted on dreaming up new things, i doubt we would've accomplished anything significant (not just in OS, anywhere ;) > Torsten -jb -- Tact is the art of making a point without making an enemy. - 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 read the FAQ at http://www.tux.org/lkml/
Re: SATA Harddisk speed drop of 100 MB/s
On Sat, 23 Jun 2007 04:59:06 +0200 Carlo Wood <[EMAIL PROTECTED]> wrote: > On Fri, Jun 22, 2007 at 10:31:32PM -0300, Henrique de Moraes Holschuh wrote: > > for i in /sys/block/sd*/queue/scheduler ; do echo -n "scheduler for $i > > was:" ; cat $i ; echo anticipatory > $i ; done > > > > Should show you the scheduler for all libata/scsi discs, and switch to > > anticipatory. It probably works for hd* as well, but I don't have any > > around to test. > > > > I had ridiculous md raid performance (on resync) using cfq at least once. > > Unfortunately I never bothered trying to track it down, and I didn't check > > the throughput after the resync was done either. Also, I don't recall the > > kernel version, but it was either 2.6.18 or 2.6.20. > > Just one kernel version? The problem here is in every > kernel revision after 551c012d7eea3dc5ec063c7ff9c718d39e77634f > > 2.6.20-rc2,rc3,rc4,rc5,rc6,rc7 ... 2.6.20 ... 2.6.21 ... 2.6.22-rc5 > > noop: > Timing buffered disk reads: 254 MB in 3.00 seconds = 84.66 MB/sec > > anticipatory: > Timing buffered disk reads: 252 MB in 3.02 seconds = 83.43 MB/sec > > deadline: > Timing buffered disk reads: 258 MB in 3.02 seconds = 85.41 MB/sec > > cfq: > Timing buffered disk reads: 194 MB in 3.03 seconds = 64.06 MB/sec > > The normal value is cfq. So, all other schedulars are somewhat faster, > but still far from the correct 165 MB/s. > Please see http://bugzilla.kernel.org/show_bug.cgi?id=8636 In that report a pretty large slowdown with CFQ has been identified. Jens has plunked a patch in there (Comment #50) and then ran away on vacation. If someone can test that patch and demonstrate its goodness, I'll queue it up, thanks. - 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 read the FAQ at http://www.tux.org/lkml/
