Re: mount-2.12r-ggk.tar.gz
On Tue, Jun 19, 2007 at 08:51:25PM +0200, Karel Zak wrote: > > > I don't think that mtab is a good place for this shared subtree > > > stuff. The mtab needs to die. > > > > Perhaps. Perhaps not. > > > > On the one hand I think there is a place for arbitrary user-space info > > about mounted filesystems. With information about who mounted, and at > > what time. What the icon is that should represent this filesystem. > > What resources are associated to this mount, and which program must do > > the cleanup. Etc. > > Today there is not much user-space info, but there is some. > > See also the "[RFC] obsoleting /etc/mtab" thread: > http://www.mail-archive.com/[EMAIL PROTECTED]/index.html#00208 Good that I am not on that mailing list - I might have spent a lot of time discussing. I see that many people agree that there is the need to attach some metadata to mounts. Good. But they suggest storing that metadata in the kernel. Bad. The kernel is not a storage place for random non-kernel-related data. A good place is a file, like /etc/mtab (I suppose today /var/run/mtab might be the appropriate place for system-wide mounts, and for user-private mounts the user can, if she wishes, indicate her favorite mtab file to use: "mount -M $HOME/foo/mtab3"). And the kernel needs non-procfs interfaces (namely syscalls) that can tell a process about its mount environment: readmounts() and statmount(). As soon as mount(8) can ask the kernel, then the problem of non-up-to-date /etc/mtab, and incomplete /proc/mounts has gone away. Andries [By the way, just like a single flat directory that contains all files turned out to be a bad idea, a single flat structure that contains all mounts will turn out soon to be a bad idea too. Some people use thousands of mounts. So, also mounts must live in a tree-structured space.] - 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: mount-2.12r-ggk.tar.gz
On Tue, Jun 19, 2007 at 04:15:28PM +0200, Karel Zak wrote: > We use GIT for development, the utils/util-linux-ng is for releases. Aha - and there have not been any releases yet. > > Anyway, Dirk Gerrits, Ren?? Gabri??l and Peter Kooijmans sent me I meant Dirk Gerrits, Ren?? Gabri??ls and Peter Kooijmans, sorry > > [By the way, this shared subtree stuff is a bit messy, > > and impossible to support correctly by mount without help > > from the kernel. So far the shared/slave/unbindable status > > of mounts is not visible in /proc/mounts or /proc/$$/mountstats. > > Unfortunately, you're right. > > We need something like /proc/PID/mounts_propagation > (see 2nd patch in): > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00136.html Hmm - mounts_new - very ugly. Reminds me of oldolduname and family. I see that you followed up and said the right things. > > The above mount makes a feeble attempt to record these flags > > in /etc/mtab, but will fail in any nontrivial situation.] > > I don't think that mtab is a good place for this shared subtree > stuff. The mtab needs to die. Perhaps. Perhaps not. On the one hand I think there is a place for arbitrary user-space info about mounted filesystems. With information about who mounted, and at what time. What the icon is that should represent this filesystem. What resources are associated to this mount, and which program must do the cleanup. Etc. Today there is not much user-space info, but there is some. On the other hand, the fact that the namespace is per-process complicates matters. There is no natural location for a per-process mtab. But maybe the easy solution is just to leave that to the users by giving mount(8) an option "-M mtabfile". What is missing is a way for user space to find out what the actual kernel situation is, and that makes /etc/mtab imperfect. The right implementation of "mount" (without options, roughly "cat /proc/mounts") would be for mount to ask the kernel about all existing mounts, merge the user space type information found in /etc/mtab, and give the result to the user. (And update mtab if necessary.) For the filesystem we have readdir() and stat() to find out about the file hierarchy. I would like readmounts() and statmount() to find out about the tree of mounts and the flags of each mount. Without using /proc. Andries - 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: mount-2.12r-ggk.tar.gz
On Tue, Jun 19, 2007 at 04:15:28PM +0200, Karel Zak wrote: We use GIT for development, the utils/util-linux-ng is for releases. Aha - and there have not been any releases yet. Anyway, Dirk Gerrits, Ren?? Gabri??l and Peter Kooijmans sent me I meant Dirk Gerrits, Ren?? Gabri??ls and Peter Kooijmans, sorry [By the way, this shared subtree stuff is a bit messy, and impossible to support correctly by mount without help from the kernel. So far the shared/slave/unbindable status of mounts is not visible in /proc/mounts or /proc/$$/mountstats. Unfortunately, you're right. We need something like /proc/PID/mounts_propagation (see 2nd patch in): http://www.mail-archive.com/[EMAIL PROTECTED]/msg00136.html Hmm - mounts_new - very ugly. Reminds me of oldolduname and family. I see that you followed up and said the right things. The above mount makes a feeble attempt to record these flags in /etc/mtab, but will fail in any nontrivial situation.] I don't think that mtab is a good place for this shared subtree stuff. The mtab needs to die. Perhaps. Perhaps not. On the one hand I think there is a place for arbitrary user-space info about mounted filesystems. With information about who mounted, and at what time. What the icon is that should represent this filesystem. What resources are associated to this mount, and which program must do the cleanup. Etc. Today there is not much user-space info, but there is some. On the other hand, the fact that the namespace is per-process complicates matters. There is no natural location for a per-process mtab. But maybe the easy solution is just to leave that to the users by giving mount(8) an option -M mtabfile. What is missing is a way for user space to find out what the actual kernel situation is, and that makes /etc/mtab imperfect. The right implementation of mount (without options, roughly cat /proc/mounts) would be for mount to ask the kernel about all existing mounts, merge the user space type information found in /etc/mtab, and give the result to the user. (And update mtab if necessary.) For the filesystem we have readdir() and stat() to find out about the file hierarchy. I would like readmounts() and statmount() to find out about the tree of mounts and the flags of each mount. Without using /proc. Andries - 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: mount-2.12r-ggk.tar.gz
On Tue, Jun 19, 2007 at 08:51:25PM +0200, Karel Zak wrote: I don't think that mtab is a good place for this shared subtree stuff. The mtab needs to die. Perhaps. Perhaps not. On the one hand I think there is a place for arbitrary user-space info about mounted filesystems. With information about who mounted, and at what time. What the icon is that should represent this filesystem. What resources are associated to this mount, and which program must do the cleanup. Etc. Today there is not much user-space info, but there is some. See also the [RFC] obsoleting /etc/mtab thread: http://www.mail-archive.com/[EMAIL PROTECTED]/index.html#00208 Good that I am not on that mailing list - I might have spent a lot of time discussing. I see that many people agree that there is the need to attach some metadata to mounts. Good. But they suggest storing that metadata in the kernel. Bad. The kernel is not a storage place for random non-kernel-related data. A good place is a file, like /etc/mtab (I suppose today /var/run/mtab might be the appropriate place for system-wide mounts, and for user-private mounts the user can, if she wishes, indicate her favorite mtab file to use: mount -M $HOME/foo/mtab3). And the kernel needs non-procfs interfaces (namely syscalls) that can tell a process about its mount environment: readmounts() and statmount(). As soon as mount(8) can ask the kernel, then the problem of non-up-to-date /etc/mtab, and incomplete /proc/mounts has gone away. Andries [By the way, just like a single flat directory that contains all files turned out to be a bad idea, a single flat structure that contains all mounts will turn out soon to be a bad idea too. Some people use thousands of mounts. So, also mounts must live in a tree-structured space.] - 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] Ignore partition table on device
On Sat, Jun 02, 2007 at 08:55:13PM +0200, Jonathan Schleifer wrote:
> This patch adds a new kernel parameter (ignore_partitions=device) to
> the kernel. It is useful when using a fake RAID with dmraid so that
> Linux won't complain about attemps to access the drive beyond its
> boundaries when udev and/or hald are started.
>
> +static char * __initdata ignore_dev;
> + if (ignore_dev != NULL && !strcmp(state->name, ignore_dev)) {
I agree that the current behaviour of touching all devices seen
at boot time is rather undesirable. It adds twenty seconds to the
boot time of my machine, where Linux tries to read nonexisting media
in the on-board usb storage devices, starting error-recovery when that
fails, etc. (These days it also seems that even when no errors occur
everything is done twice - maybe a libata bug, I have not looked,
attached a dmesg fragment.) And the unasked-for guessing has caused
a thin trickle of problems for over ten years.
But this patch is not really an improvement.
It allows you to tell about a single device that the kernel should
not try to find a partition table there, because even if it finds
something that resembles a partition table, it would be mistaken.
The general case is that one wants to say the same thing about
several devices - if you ask me, about all devices, except possibly
for an explicitly specified boot device.
It should be userspace that directs the kernel to probe a device.
It should be udev or some such program that tells the kernel to
look for a partition table on a newly found device. Perhaps even
for a partition table of known type. Or maybe userspace does the
looking itself, using partx or so - sometimes userspace knows better
what to expect.
Maybe there already is such an option in the vanilla kernel,
but if there isnt't it should be added: noautoreadpt.
Andries
"done twice":
[ 26.505536] SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
[ 26.505584] sda: Write Protect is off
[ 26.505616] sda: Mode Sense: 00 3a 00 00
[ 26.505630] SCSI device sda: write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 26.505713] SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
[ 26.505755] sda: Write Protect is off
[ 26.505787] sda: Mode Sense: 00 3a 00 00
[ 26.505801] SCSI device sda: write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 26.505844] sda: sda1 sda2 < sda5 >
[ 26.535025] sd 0:0:0:0: Attached scsi disk sda
"done twice":
[ 25.839447] scsi6 : SCSI emulation for USB Mass Storage devices
[ 30.844107] sd 6:0:0:0: Attached scsi removable disk sdb
[ 42.519502] sdb : READ CAPACITY failed.
[ 42.770997] scsi7 : SCSI emulation for USB Mass Storage devices
[ 48.024083] sd 7:0:0:0: Attached scsi removable disk sdb
[ 49.326683] sdb : READ CAPACITY failed.
[ 49.331174] scsi 7:0:0:0: rejecting I/O to dead device
There is nothing wrong with sdb (and sdc, sdd, sde).
They are just USB card readers without media.
This is an Ubuntu 2.6.20 kernel.
-
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] Ignore partition table on device
On Sat, Jun 02, 2007 at 08:55:13PM +0200, Jonathan Schleifer wrote:
This patch adds a new kernel parameter (ignore_partitions=device) to
the kernel. It is useful when using a fake RAID with dmraid so that
Linux won't complain about attemps to access the drive beyond its
boundaries when udev and/or hald are started.
+static char * __initdata ignore_dev;
+ if (ignore_dev != NULL !strcmp(state-name, ignore_dev)) {
I agree that the current behaviour of touching all devices seen
at boot time is rather undesirable. It adds twenty seconds to the
boot time of my machine, where Linux tries to read nonexisting media
in the on-board usb storage devices, starting error-recovery when that
fails, etc. (These days it also seems that even when no errors occur
everything is done twice - maybe a libata bug, I have not looked,
attached a dmesg fragment.) And the unasked-for guessing has caused
a thin trickle of problems for over ten years.
But this patch is not really an improvement.
It allows you to tell about a single device that the kernel should
not try to find a partition table there, because even if it finds
something that resembles a partition table, it would be mistaken.
The general case is that one wants to say the same thing about
several devices - if you ask me, about all devices, except possibly
for an explicitly specified boot device.
It should be userspace that directs the kernel to probe a device.
It should be udev or some such program that tells the kernel to
look for a partition table on a newly found device. Perhaps even
for a partition table of known type. Or maybe userspace does the
looking itself, using partx or so - sometimes userspace knows better
what to expect.
Maybe there already is such an option in the vanilla kernel,
but if there isnt't it should be added: noautoreadpt.
Andries
done twice:
[ 26.505536] SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
[ 26.505584] sda: Write Protect is off
[ 26.505616] sda: Mode Sense: 00 3a 00 00
[ 26.505630] SCSI device sda: write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 26.505713] SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
[ 26.505755] sda: Write Protect is off
[ 26.505787] sda: Mode Sense: 00 3a 00 00
[ 26.505801] SCSI device sda: write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 26.505844] sda: sda1 sda2 sda5
[ 26.535025] sd 0:0:0:0: Attached scsi disk sda
done twice:
[ 25.839447] scsi6 : SCSI emulation for USB Mass Storage devices
[ 30.844107] sd 6:0:0:0: Attached scsi removable disk sdb
[ 42.519502] sdb : READ CAPACITY failed.
[ 42.770997] scsi7 : SCSI emulation for USB Mass Storage devices
[ 48.024083] sd 7:0:0:0: Attached scsi removable disk sdb
[ 49.326683] sdb : READ CAPACITY failed.
[ 49.331174] scsi 7:0:0:0: rejecting I/O to dead device
There is nothing wrong with sdb (and sdc, sdd, sde).
They are just USB card readers without media.
This is an Ubuntu 2.6.20 kernel.
-
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 pata-2.6 fix queue] hpt366: don't check enablebits for HPT36x
On Fri, May 04, 2007 at 11:18:37PM +0400, Sergei Shtylyov wrote: > HPT36x chip don't seem to have the channel enable bits, > so prevent the IDE core from checking them... > > Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]> Earlier this evening I reported that HPT366 was broken in 2.6.21. I confirm that this fixes it for me. Andries - 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 pata-2.6 fix queue] hpt366: don't check enablebits for HPT36x
On Fri, May 04, 2007 at 11:18:37PM +0400, Sergei Shtylyov wrote: HPT36x chip don't seem to have the channel enable bits, so prevent the IDE core from checking them... Signed-off-by: Sergei Shtylyov [EMAIL PROTECTED] Earlier this evening I reported that HPT366 was broken in 2.6.21. I confirm that this fixes it for me. Andries - 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: console font limits
On Tue, May 01, 2007 at 12:09:46AM -0400, Albert Cahalan wrote:
> I'm having problems with a font I just created. It's a rather big one,
> intended for a framebuffer console in UTF-8 mode. The strace program
> reports that /bin/setfont fails on a KDFONTOP ioctl with EINVAL.
> In reading the kernel code, I find this:
>
> vt.c:static int con_font_set(struct vc_data *vc, struct console_font_op *op)
> vt.c-{
> vt.c- struct console_font font;
> vt.c- int rc = -EINVAL;
> vt.c- int size;
> vt.c-
> vt.c- if (vc->vc_mode != KD_TEXT)
> vt.c- return -EINVAL;
> vt.c- if (!op->data)
> vt.c- return -EINVAL;
> vt.c- if (op->charcount > 512)
> vt.c- return -EINVAL;
>
> Ouch. Why is the old VGA limit being applied to the framebuffer console?
This is common code, for both framebuffer and vga.
If you want you can push this check into the individual foo->con_font_set
routines. Have some check here that the total size is not ridiculous.
(There is a loop
for (i = 0; i < op->charcount; i++)
that must have some bounded length. Easiest is to test against the total
font size some lines later:
size = (op->width+7)/8 * 32 * op->charcount;
if (size > max_font_size)
return -ENOSPC;
E.g., move this up so that it becomes
if (op->width <= 0 || op->width > 32)
return -EINVAL;
if (op->charcount > max_font_size / 32 / ((op->width+7)/8))
return -ENOSPC;
.)
> I nearly hit the 32-pixel height limit as well, yet another relic from
> the VGA hardware. I also nearly hit the 64 KB font size limit.
Of course you can make everything more general if you want to and need to.
Some of this code was written when average machines had 4 or 8 MB of memory.
On the other hand, for VGA some of the limits are hardware restrictions.
> Currently I'm doing a 15x30 font with 870 glyphs to represent 978
> different Unicode code points. This is for a 200 DPI display with
> an anti-aliasing filter, so fonts need to be big. I'm considering 15x36
> so that I'll have more room for double-accented letters, but clearly
> the kernel would block that too.
In case you generalize stuff in such a way that also the kbd package
needs an update, write.
> BTW, the PSF font format documentation seems to suggest that
> there is a way to make the kernel handle combining accents:
> http://www.win.tue.nl/~aeb/linux/kbd/font-formats-1.html
> Does anybody know if that really works? I could sure use that.
Well, the PSF font format documentation shows that there is a way
to document in a font that some font position represents a
sequence of Unicode values. Whether the kernel is able to
use such information depends on the kernel version - maybe vanilla
kernels cannot.
[Very long ago I wrote Yiddish songs on the console, German on the left,
Yiddish on the right, and made a bidirectional console for this purpose.
Long ago I wrote Tibetan on the console and added enough input- and
output stuff to make that work. Only a small part of this has ended up
in the vanilla kernel. Adding features to the console is not a popular idea.]
Get the kbd package and read kdmapop.c for the docs on the kbd ioctls.
Tell me if these docs are outdated. I read
/*
* Linux pre-0.96 defined GIO_SCRNMAP, PIO_SCRNMAP:
typedef char scrnmap_t;
#define E_TABSZ 256
#define GIO_SCRNMAP 0x4B40
#define PIO_SCRNMAP 0x4B41
* and Linux 0.99.14y first implemented them.
* Usage:
scrnmap_t map[E_TABSZ];
ioctl(fd,GIO_SCRNMAP,map);
ioctl(fd,PIO_SCRNMAP,map);
* to read or write the kernel translation table that is
* applied to user application output before displaying.
*
* Before 1.3.1, the character set was completely undetermined,
* and if the font was in an order different from the character
* set in use, the user screen map was used to map application
* codes to font indices. (To be more precise: there were four
* translation tables, and this ioctl would get/set the fourth
* table, while the other three tables are built-in and constant.)
*/
/*
* Linux 1.3.1 introduces GIO_UNISCRNMAP, PIO_UNISCRNMAP:
#define GIO_UNISCRNMAP 0x4B69
#define PIO_UNISCRNMAP 0x4B6A
* Usage:
unsigned short umap[E_TABSZ];
ioctl(fd,GIO_UNISCRNMAP,umap);
ioctl(fd,PIO_UNISCRNMAP,umap);
* to read or write the kernel translation table that is
* applied to user application output before displaying.
* (When the console is not in utf8 mode.)
*
* The idea is that the umap values are 16-bit unicode (ucs2)
* values, and that the fonts will have an index giving the
* unicode value for each glyph, so that the kernel can match up
* application codes to font positions.
#define UNI_DIRECT_BASE 0xF000
#define UNI_DIRECT_MASK 0x01FF
* For compatibility, and for fonts without table, the unicode
* values 0xF000+n, 0 <= n <= 0x01FF, acts as direct font indices.
* In the new scheme,
Re: console font limits
On Tue, May 01, 2007 at 12:09:46AM -0400, Albert Cahalan wrote:
I'm having problems with a font I just created. It's a rather big one,
intended for a framebuffer console in UTF-8 mode. The strace program
reports that /bin/setfont fails on a KDFONTOP ioctl with EINVAL.
In reading the kernel code, I find this:
vt.c:static int con_font_set(struct vc_data *vc, struct console_font_op *op)
vt.c-{
vt.c- struct console_font font;
vt.c- int rc = -EINVAL;
vt.c- int size;
vt.c-
vt.c- if (vc-vc_mode != KD_TEXT)
vt.c- return -EINVAL;
vt.c- if (!op-data)
vt.c- return -EINVAL;
vt.c- if (op-charcount 512)
vt.c- return -EINVAL;
Ouch. Why is the old VGA limit being applied to the framebuffer console?
This is common code, for both framebuffer and vga.
If you want you can push this check into the individual foo-con_font_set
routines. Have some check here that the total size is not ridiculous.
(There is a loop
for (i = 0; i op-charcount; i++)
that must have some bounded length. Easiest is to test against the total
font size some lines later:
size = (op-width+7)/8 * 32 * op-charcount;
if (size max_font_size)
return -ENOSPC;
E.g., move this up so that it becomes
if (op-width = 0 || op-width 32)
return -EINVAL;
if (op-charcount max_font_size / 32 / ((op-width+7)/8))
return -ENOSPC;
.)
I nearly hit the 32-pixel height limit as well, yet another relic from
the VGA hardware. I also nearly hit the 64 KB font size limit.
Of course you can make everything more general if you want to and need to.
Some of this code was written when average machines had 4 or 8 MB of memory.
On the other hand, for VGA some of the limits are hardware restrictions.
Currently I'm doing a 15x30 font with 870 glyphs to represent 978
different Unicode code points. This is for a 200 DPI display with
an anti-aliasing filter, so fonts need to be big. I'm considering 15x36
so that I'll have more room for double-accented letters, but clearly
the kernel would block that too.
In case you generalize stuff in such a way that also the kbd package
needs an update, write.
BTW, the PSF font format documentation seems to suggest that
there is a way to make the kernel handle combining accents:
http://www.win.tue.nl/~aeb/linux/kbd/font-formats-1.html
Does anybody know if that really works? I could sure use that.
Well, the PSF font format documentation shows that there is a way
to document in a font that some font position represents a
sequence of Unicode values. Whether the kernel is able to
use such information depends on the kernel version - maybe vanilla
kernels cannot.
[Very long ago I wrote Yiddish songs on the console, German on the left,
Yiddish on the right, and made a bidirectional console for this purpose.
Long ago I wrote Tibetan on the console and added enough input- and
output stuff to make that work. Only a small part of this has ended up
in the vanilla kernel. Adding features to the console is not a popular idea.]
Get the kbd package and read kdmapop.c for the docs on the kbd ioctls.
Tell me if these docs are outdated. I read
/*
* Linux pre-0.96 defined GIO_SCRNMAP, PIO_SCRNMAP:
typedef char scrnmap_t;
#define E_TABSZ 256
#define GIO_SCRNMAP 0x4B40
#define PIO_SCRNMAP 0x4B41
* and Linux 0.99.14y first implemented them.
* Usage:
scrnmap_t map[E_TABSZ];
ioctl(fd,GIO_SCRNMAP,map);
ioctl(fd,PIO_SCRNMAP,map);
* to read or write the kernel translation table that is
* applied to user application output before displaying.
*
* Before 1.3.1, the character set was completely undetermined,
* and if the font was in an order different from the character
* set in use, the user screen map was used to map application
* codes to font indices. (To be more precise: there were four
* translation tables, and this ioctl would get/set the fourth
* table, while the other three tables are built-in and constant.)
*/
/*
* Linux 1.3.1 introduces GIO_UNISCRNMAP, PIO_UNISCRNMAP:
#define GIO_UNISCRNMAP 0x4B69
#define PIO_UNISCRNMAP 0x4B6A
* Usage:
unsigned short umap[E_TABSZ];
ioctl(fd,GIO_UNISCRNMAP,umap);
ioctl(fd,PIO_UNISCRNMAP,umap);
* to read or write the kernel translation table that is
* applied to user application output before displaying.
* (When the console is not in utf8 mode.)
*
* The idea is that the umap values are 16-bit unicode (ucs2)
* values, and that the fonts will have an index giving the
* unicode value for each glyph, so that the kernel can match up
* application codes to font positions.
#define UNI_DIRECT_BASE 0xF000
#define UNI_DIRECT_MASK 0x01FF
* For compatibility, and for fonts without table, the unicode
* values 0xF000+n, 0 = n = 0x01FF, acts as direct font indices.
* In the new scheme, the old PIO_SCRNMAP fills the kernel umap
* table
Re: [PATCH] partitions: Enhance Kconfig help text for EESOX and MSDOS formats
On Sat, Apr 07, 2007 at 01:27:09PM -0400, John Anthony Kazos Jr. wrote: > From: John Anthony Kazos Jr. <[EMAIL PROTECTED]> > > improves help text for MSDOS_PARTITION in fs/partitions/Kconfig. > @@ -108,7 +112,11 @@ config MSDOS_PARTITION > bool "PC BIOS (MSDOS partition tables) support" if PARTITION_ADVANCED > default y > help > - Say Y here. > + Standard PC-compatible partition table support for Linux. Used by > + i386 systems, Linux/Windows dual-boot systems, and many others. > + Unless you are certain your system does not use this partition > + table format, and you're not using any disks from a system that > + does, say Y. > > config BSD_DISKLABEL > bool "BSD disklabel (FreeBSD partition tables) support" This is not an improvement. "Say Y here" is the correct advice to everybody. In cases where someone does not have any DOS-type partition tables on his machine, he probably has a digital camera, or MP3 player or USB stick or other device that uses such partition tables. - 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] partitions: Enhance Kconfig help text for EESOX and MSDOS formats
On Sat, Apr 07, 2007 at 01:27:09PM -0400, John Anthony Kazos Jr. wrote: From: John Anthony Kazos Jr. [EMAIL PROTECTED] improves help text for MSDOS_PARTITION in fs/partitions/Kconfig. @@ -108,7 +112,11 @@ config MSDOS_PARTITION bool PC BIOS (MSDOS partition tables) support if PARTITION_ADVANCED default y help - Say Y here. + Standard PC-compatible partition table support for Linux. Used by + i386 systems, Linux/Windows dual-boot systems, and many others. + Unless you are certain your system does not use this partition + table format, and you're not using any disks from a system that + does, say Y. config BSD_DISKLABEL bool BSD disklabel (FreeBSD partition tables) support This is not an improvement. Say Y here is the correct advice to everybody. In cases where someone does not have any DOS-type partition tables on his machine, he probably has a digital camera, or MP3 player or USB stick or other device that uses such partition tables. - 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: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)
On Sat, Jan 20, 2007 at 09:08:47AM +0100, Michał Kudła wrote: > Hello, > after > ... > hdb: max request size: 512KiB > hdb: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, > > Should be everywere KiB, MiB, GiB, ... according to IEC 60027-2 You are mistaken. The MB here are actual megabytes (million bytes), not MiB. Read the code, or do the computation: 488397168*512 = 250059350016. (Precisely what one wants - the kernel gives the correct size, just like the disk manufacturers, and there is no discrepancy. Binary abuse for decimal prefixes is a sloppiness that might be acceptable for stuff that naturally comes in powers of two. It is long ago that that was true for disks.) Andries - 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: PROBLEM: KB-KiB, MB - MiB, ... (IEC 60027-2)
On Sat, Jan 20, 2007 at 09:08:47AM +0100, Michał Kudła wrote: Hello, after ... hdb: max request size: 512KiB hdb: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63, Should be everywere KiB, MiB, GiB, ... according to IEC 60027-2 You are mistaken. The MB here are actual megabytes (million bytes), not MiB. Read the code, or do the computation: 488397168*512 = 250059350016. (Precisely what one wants - the kernel gives the correct size, just like the disk manufacturers, and there is no discrepancy. Binary abuse for decimal prefixes is a sloppiness that might be acceptable for stuff that naturally comes in powers of two. It is long ago that that was true for disks.) Andries - 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: Ext3 mounted as ext2 but journal still in effect.
>> You were right, even after making the changes, it seems to be >> telling lies: >> >> # mount >> /dev/hda2 on / type ext2 (rw,usrquota) Roughly speaking: /etc/mtab shows you what you said to mount. /proc/mounts shows what the current kernel state is. These may differ greatly. For all filesystems mounted by you using mount(8), a line is added to /etc/mtab, where the contents of that line is related to the given mount command, but not to what the kernel did. For the root filesystem, mount(8) writes an initial line in /etc/mtab taken from /etc/fstab. Again the information is from you, not from the kernel. >> # dmesg | grep 'Kernel command' >> Kernel command line: ro root=/dev/hda2 rootfstype=ext2 > ... >> /dev/root / ext3 rw 0 0 It would be a bad bug if the kernel mounted its root filesystem with a type different from the type given in "rootfstype=". But I see you use an initrd, and there can be all kinds of commands there. - 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: Ext3 mounted as ext2 but journal still in effect.
You were right, even after making the changes, it seems to be telling lies: # mount /dev/hda2 on / type ext2 (rw,usrquota) Roughly speaking: /etc/mtab shows you what you said to mount. /proc/mounts shows what the current kernel state is. These may differ greatly. For all filesystems mounted by you using mount(8), a line is added to /etc/mtab, where the contents of that line is related to the given mount command, but not to what the kernel did. For the root filesystem, mount(8) writes an initial line in /etc/mtab taken from /etc/fstab. Again the information is from you, not from the kernel. # dmesg | grep 'Kernel command' Kernel command line: ro root=/dev/hda2 rootfstype=ext2 ... /dev/root / ext3 rw 0 0 It would be a bad bug if the kernel mounted its root filesystem with a type different from the type given in rootfstype=. But I see you use an initrd, and there can be all kinds of commands there. - 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: 2.6 Partitioning bug with LILO
On Fri, Jan 12, 2007 at 06:18:00PM -0500, Kris Karas wrote: > Hello Andries, > > I noticed you're listed as the maintainer for the disk > geometry/partitioning logic in the 2.6 kernel, so I'm sending this to > you, as I think this bug is most likely in that part of the code, ... > > I've been bug-hunting with John Coffman to solve an issue where running > LILO trashes the ext2 metadata on my /boot partition. The consensus so > far is that it's not LILO at all, but rather some subtle bug in the > kernel that's the culprit. I can reproduce it easily enough on 2.6, but > not on 2.4, which further suggests its kernel-related. > > If one does: > > umount /boot > e2fsck -f -y /dev/hda1 > mount /dev/hda1 /boot > lilo > umount /boot > e2fsck -f -y /dev/hda1 > > the second run of e2fsck will report fixable block bitmap errors. It is easy to see the cause of this. There is an old problem with the Linux whole disk device /dev/hda namely that there is aliasing with /dev/hdaN. I don't know whether there exist kernels that fix this problem - as far as I know this has been a problem since ancient times. But, given the fact that this is a well-known problem of the kernel, a utility should be careful to avoid problems and flush buffers at appropriate times. Now that lilo is one of the few utilities to write to /dev/hda, it should be fixed. [And yes, also the kernel should be fixed.] Andries [let me cc linux-kernel] - 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: 2.6 Partitioning bug with LILO
On Fri, Jan 12, 2007 at 06:18:00PM -0500, Kris Karas wrote: Hello Andries, I noticed you're listed as the maintainer for the disk geometry/partitioning logic in the 2.6 kernel, so I'm sending this to you, as I think this bug is most likely in that part of the code, ... I've been bug-hunting with John Coffman to solve an issue where running LILO trashes the ext2 metadata on my /boot partition. The consensus so far is that it's not LILO at all, but rather some subtle bug in the kernel that's the culprit. I can reproduce it easily enough on 2.6, but not on 2.4, which further suggests its kernel-related. If one does: umount /boot e2fsck -f -y /dev/hda1 mount /dev/hda1 /boot lilo umount /boot e2fsck -f -y /dev/hda1 the second run of e2fsck will report fixable block bitmap errors. It is easy to see the cause of this. There is an old problem with the Linux whole disk device /dev/hda namely that there is aliasing with /dev/hdaN. I don't know whether there exist kernels that fix this problem - as far as I know this has been a problem since ancient times. But, given the fact that this is a well-known problem of the kernel, a utility should be careful to avoid problems and flush buffers at appropriate times. Now that lilo is one of the few utilities to write to /dev/hda, it should be fixed. [And yes, also the kernel should be fixed.] Andries [let me cc linux-kernel] - 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] Minix V3 support
On Mon, Jan 08, 2007 at 04:06:53PM -0800, Andrew Morton wrote: > Daniel, it'd be good if you could review and test these changes please. > > Also, a signed-off-by from yourself and from Andries, please... Signed-off-by: Andries Brouwer <[EMAIL PROTECTED]> Andries - 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] Minix V3 support
On Mon, Jan 08, 2007 at 04:06:53PM -0800, Andrew Morton wrote: Daniel, it'd be good if you could review and test these changes please. Also, a signed-off-by from yourself and from Andries, please... Signed-off-by: Andries Brouwer [EMAIL PROTECTED] Andries - 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: fs/partitions/msdos.c, scripts/packages/Makefile
On Fri, Apr 01, 2005 at 07:18:52PM +0200, Uwe Zybell wrote: > There is a line in fs/partitions/msdos.c that lets extended partitions > be max 1k (..."==1 ? 1 : 2"...). The comment explains it to protect > sysadmins from themselves. But now I have found a legitimate use > for extended partitions in their full length. Emulation. > Please remove this, or make it a config option. Config options are evil. Adding them is a bad form of bloat. Whatever you want to do, there are many ways to do it without changing this part of the kernel code. After all, any partition is just part of the entire disk. Note that there are aliasing problems - it is bad to access data both via a file system and via raw disk or partition. Andries - 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: fs/partitions/msdos.c, scripts/packages/Makefile
On Fri, Apr 01, 2005 at 07:18:52PM +0200, Uwe Zybell wrote: There is a line in fs/partitions/msdos.c that lets extended partitions be max 1k (...==1 ? 1 : 2...). The comment explains it to protect sysadmins from themselves. But now I have found a legitimate use for extended partitions in their full length. Emulation. Please remove this, or make it a config option. Config options are evil. Adding them is a bad form of bloat. Whatever you want to do, there are many ways to do it without changing this part of the kernel code. After all, any partition is just part of the entire disk. Note that there are aliasing problems - it is bad to access data both via a file system and via raw disk or partition. Andries - 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 0/9] isofs: unobfuscate rock.c
On Mon, Mar 28, 2005 at 12:02:52PM -0800, Chris Wright wrote: > * Pekka Enberg ([EMAIL PROTECTED]) wrote: > > This patch removes macro obfuscation from fs/isofs/rock.c and cleans it up > > a bit to make it more readable and maintainable. There are no functional > > changes, only cleanups. I have only tested this lightly but it passes > > mount and read on small Rock Ridge enabled ISO image. > > You might want to look at current -mm. Andrew has a series or 13 or so > patches that do very similar cleanup. Perhaps you could start from there? Good! When Linus asked I audited rock.c and also did rather similar polishing - it happens automatically if one looks at this code. But it seems everybody is doing this right now, so I must wait a few weeks and see what got into Linus' tree. Linus plugged many but not all holes. (Maybe you did more?) Andries - 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 0/9] isofs: unobfuscate rock.c
On Mon, Mar 28, 2005 at 12:02:52PM -0800, Chris Wright wrote: * Pekka Enberg ([EMAIL PROTECTED]) wrote: This patch removes macro obfuscation from fs/isofs/rock.c and cleans it up a bit to make it more readable and maintainable. There are no functional changes, only cleanups. I have only tested this lightly but it passes mount and read on small Rock Ridge enabled ISO image. You might want to look at current -mm. Andrew has a series or 13 or so patches that do very similar cleanup. Perhaps you could start from there? Good! When Linus asked I audited rock.c and also did rather similar polishing - it happens automatically if one looks at this code. But it seems everybody is doing this right now, so I must wait a few weeks and see what got into Linus' tree. Linus plugged many but not all holes. (Maybe you did more?) Andries - 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: OOM problems on 2.6.12-rc1 with many fsx tests
On Wed, Mar 23, 2005 at 03:20:55PM -0800, Andrew Morton wrote: > Nothing beats poking around in a dead machine's guts with kgdb though. Everyone his taste. But I was surprised by > SwapTotal: 1052216 kB > SwapFree: 1045984 kB Strange that processes are killed while lots of swap is available. Andries - 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: SVGATextMode on 2.6.11
> "Alan Curry" <[EMAIL PROTECTED]> wrote: >> >> With 2.6.11, I can no longer change the cursor with SVGATextMode. Previously, >> a block cursor could be selected by >> echo Cursor 0-31 >> /etc/TextConfig ; SVGATextMode >> and the cursor would be a block. On all consoles. Forever. >> >> To accomplish the same thing using the softcursor escape sequences, I must: >> 1. at boot, echo '^[[?8c' to each of /dev/tty1 through /dev/tty63. >> 2. hack terminfo to contain ^[[?8c in place of ^[[?0c >> 3. install the hacked terminfo on all other machines that I will log into >> remotely >> >> This still isn't quite right: the reset sequence ^[c destroys the block >> cursor because the underline cursor is still the default. Have you tried to recompile with a different default? Look at , and change the line #define CUR_DEFAULT CUR_UNDERLINE to e.g. #define CUR_DEFAULT CUR_BLOCK >> An SVGATextMode >> block cursor isn't affected by ^[c -- it truly *becomes* the default True - it is obtained by hardware reprogramming. But having lots of programs touch the hardware is getting less popular. Concerning your 1. - You know that such an echo actually creates the VC? I still recall the times that there was not enough memory for more than four or five VCs, but probably you don't mind wasting a few hundred kB. Andries - 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: SVGATextMode on 2.6.11
Alan Curry [EMAIL PROTECTED] wrote: With 2.6.11, I can no longer change the cursor with SVGATextMode. Previously, a block cursor could be selected by echo Cursor 0-31 /etc/TextConfig ; SVGATextMode and the cursor would be a block. On all consoles. Forever. To accomplish the same thing using the softcursor escape sequences, I must: 1. at boot, echo '^[[?8c' to each of /dev/tty1 through /dev/tty63. 2. hack terminfo to contain ^[[?8c in place of ^[[?0c 3. install the hacked terminfo on all other machines that I will log into remotely This still isn't quite right: the reset sequence ^[c destroys the block cursor because the underline cursor is still the default. Have you tried to recompile with a different default? Look at linux/console_struct.h, and change the line #define CUR_DEFAULT CUR_UNDERLINE to e.g. #define CUR_DEFAULT CUR_BLOCK An SVGATextMode block cursor isn't affected by ^[c -- it truly *becomes* the default True - it is obtained by hardware reprogramming. But having lots of programs touch the hardware is getting less popular. Concerning your 1. - You know that such an echo actually creates the VC? I still recall the times that there was not enough memory for more than four or five VCs, but probably you don't mind wasting a few hundred kB. Andries - 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: Devices/Partitions over 2TB
On Mon, Mar 14, 2005 at 10:44:31AM -0600, Berkley Shands wrote: > With a Broadcom BC4852 and suitable Sata drives, it is easy to create > functional devices with well in excess of 2TB raw space. This presents a > severe > problem to partitioning tools, such as fdisk/cfdisk and the like as the > kernel partition structure has a 32 bit integer max for sector counts. Since > the read_int() function combined with cround() overflows, ... You should not read fdisk source but think about the DOS-type partition table. An entry in such a table describes partition start and end in CHS terms using 24 bits for start and end, and describes partition start and size in LBA terms using 32 bits for start and size. If you use sectors of size 512, that limits the use of DOS-type partition tables to disks of at most 2^41 bytes, that is, 2 TiB. What to do afterwards? Last year I made a hack, reserving type 88 hex for a Linux plaintext partition table. You must be able to find the kernel patch somewhere on Google, otherwise ask. No fdisk required, the partition table is just plaintext that you edit using emacs or vi. The idea here is to use an ordinary DOS-type partition table for the start of the disk, and let the type 88 partition describe the rest. There is also the EFI/GPT disk descriptor that is common on IA64, but not much used elsewhere. Maybe parted supports it. Andries - 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: Devices/Partitions over 2TB
On Mon, Mar 14, 2005 at 10:44:31AM -0600, Berkley Shands wrote: With a Broadcom BC4852 and suitable Sata drives, it is easy to create functional devices with well in excess of 2TB raw space. This presents a severe problem to partitioning tools, such as fdisk/cfdisk and the like as the kernel partition structure has a 32 bit integer max for sector counts. Since the read_int() function combined with cround() overflows, ... You should not read fdisk source but think about the DOS-type partition table. An entry in such a table describes partition start and end in CHS terms using 24 bits for start and end, and describes partition start and size in LBA terms using 32 bits for start and size. If you use sectors of size 512, that limits the use of DOS-type partition tables to disks of at most 2^41 bytes, that is, 2 TiB. What to do afterwards? Last year I made a hack, reserving type 88 hex for a Linux plaintext partition table. You must be able to find the kernel patch somewhere on Google, otherwise ask. No fdisk required, the partition table is just plaintext that you edit using emacs or vi. The idea here is to use an ordinary DOS-type partition table for the start of the disk, and let the type 88 partition describe the rest. There is also the EFI/GPT disk descriptor that is common on IA64, but not much used elsewhere. Maybe parted supports it. Andries - 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: link(2) and symlinks
On Wed, Mar 09, 2005 at 03:14:36PM -0800, Nick Stoughton wrote: > On Linux, the link() system call does not dereference symbolic links > > This behavior does not conform to POSIX > > Most Unix implementations behave in the manner specified by POSIX. One > notable exception is Solaris 8 (I don't know about later Solarises). > > Would a patch to provide POSIX conforming behavior under some > conditional case (e.g. if /proc/sys/posix has value 1) ever be accepted? It sounds like a bad idea to have name resolution semantics dependent upon some external variable. The result would be that nobody could be sure anymore what the link() system call will do. (Also, POSIX does not describe the kernel interface - it describes a C interface. It would be possible for a libc to arrange that a different link() routine was used. Use of personality(2) does not sound like a good idea.) ((Maybe it would be beter to change POSIX here. Submit a defect report and make the result of hard-linking to a symlink unspecified. Since Linux and Solaris are non-POSIX here, programmers of portable programs cannot rely on POSIX anyway. Moreover, the Linux/Solaris behaviour sounds entirely reasonable, preferable in fact above the POSIX behaviour.)) Andries - 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] remove dead cyrix/centaur mtrr init code
On Wed, Mar 09, 2005 at 04:55:27PM +, Alan Cox wrote: > > [PATCH] remove dead cyrix/centaur mtrr init code > > This patch was discussed previously and declared incorrect. The ->init > method call is missing in the base mtrr code. > > Should be reverted and/or fixed properly. Hi Alan - a surprising reaction. The patch is an improvement - it #ifdef's out some dead code. I sent you a follow-up patch that activates the dead code, since you said I have one here running 2.4 still. I can test a 2.6 fix for the mtrr init happily enough. But so far you have not replied. The moment you report that the follow-up patch is fine, we can remove the #if 0 and insert the initcalls instead. So, all is well today, and we are waiting for your report. Andries - 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] remove dead cyrix/centaur mtrr init code
On Wed, Mar 09, 2005 at 04:55:27PM +, Alan Cox wrote: [PATCH] remove dead cyrix/centaur mtrr init code This patch was discussed previously and declared incorrect. The -init method call is missing in the base mtrr code. Should be reverted and/or fixed properly. Hi Alan - a surprising reaction. The patch is an improvement - it #ifdef's out some dead code. I sent you a follow-up patch that activates the dead code, since you said I have one here running 2.4 still. I can test a 2.6 fix for the mtrr init happily enough. But so far you have not replied. The moment you report that the follow-up patch is fine, we can remove the #if 0 and insert the initcalls instead. So, all is well today, and we are waiting for your report. Andries - 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: link(2) and symlinks
On Wed, Mar 09, 2005 at 03:14:36PM -0800, Nick Stoughton wrote: On Linux, the link() system call does not dereference symbolic links This behavior does not conform to POSIX Most Unix implementations behave in the manner specified by POSIX. One notable exception is Solaris 8 (I don't know about later Solarises). Would a patch to provide POSIX conforming behavior under some conditional case (e.g. if /proc/sys/posix has value 1) ever be accepted? It sounds like a bad idea to have name resolution semantics dependent upon some external variable. The result would be that nobody could be sure anymore what the link() system call will do. (Also, POSIX does not describe the kernel interface - it describes a C interface. It would be possible for a libc to arrange that a different link() routine was used. Use of personality(2) does not sound like a good idea.) ((Maybe it would be beter to change POSIX here. Submit a defect report and make the result of hard-linking to a symlink unspecified. Since Linux and Solaris are non-POSIX here, programmers of portable programs cannot rely on POSIX anyway. Moreover, the Linux/Solaris behaviour sounds entirely reasonable, preferable in fact above the POSIX behaviour.)) Andries - 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: dm-crypt vs. cryptoloop reminder
On Sat, Mar 05, 2005 at 10:35:24PM +0100, Alexander Nyberg wrote: > 2.6.3-mm1 'dm-crypt vs. cryptoloop' discussion was some time ago, it is > time to bring this up again: > http://kerneltrap.org/node/2433 Are you a troll? This is not something to be quoted by anybody serious. Andrew referred to "well-known weaknesses" in cryptoloop, and when I inquired it turned out that what he referred to were properties of cryptoloop and dm-crypt alike, so that his remarks that started that discussion were misguided. Of course people may prefer dm-crypt or cryptoloop or loop-aes, just like people prefer ide-cd or ide-scsi. I have not yet seen a valid reason to deprecate one of these three very soon. Andries - 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: [RFQ] Rules for accepting patches into the linux-releases tree
On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote: > Anything else anyone can think of? Any objections to any of these? > I based them off of Linus's original list. > > thanks, > > greg k-h > > -- > > Rules on what kind of patches are accepted, and what ones are not, into > the "linux-release" tree. > > - It can not bigger than 100 lines, with context. > - It must fix only one thing. > - It must fix a real bug that bothers people (not a, "This could be a >problem..." type thing.) > - It must fix a problem that causes a build error (but not for things >marked CONFIG_BROKEN), an oops, a hang, or a real security issue. > - No "theoretical race condition" issues, unless an explanation of how >the race can be exploited. > - It can not contain any "trivial" fixes in it (spelling changes, >whitespace cleanups, etc.) Objections - no. Anything else - yes. I would like the requirement: "It must be obviously correct". In a hundred lines one can put a lot of tricky code and subtle changes. For example, if a security problem necessitates a nontrivial change, it should cause an earlier release of 2.6.x+1 instead of a 2.6.x.y+1. Andries - 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: [RFQ] Rules for accepting patches into the linux-releases tree
On Fri, Mar 04, 2005 at 02:21:46PM -0800, Greg KH wrote: Anything else anyone can think of? Any objections to any of these? I based them off of Linus's original list. thanks, greg k-h -- Rules on what kind of patches are accepted, and what ones are not, into the linux-release tree. - It can not bigger than 100 lines, with context. - It must fix only one thing. - It must fix a real bug that bothers people (not a, This could be a problem... type thing.) - It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, or a real security issue. - No theoretical race condition issues, unless an explanation of how the race can be exploited. - It can not contain any trivial fixes in it (spelling changes, whitespace cleanups, etc.) Objections - no. Anything else - yes. I would like the requirement: It must be obviously correct. In a hundred lines one can put a lot of tricky code and subtle changes. For example, if a security problem necessitates a nontrivial change, it should cause an earlier release of 2.6.x+1 instead of a 2.6.x.y+1. Andries - 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: dm-crypt vs. cryptoloop reminder
On Sat, Mar 05, 2005 at 10:35:24PM +0100, Alexander Nyberg wrote: 2.6.3-mm1 'dm-crypt vs. cryptoloop' discussion was some time ago, it is time to bring this up again: http://kerneltrap.org/node/2433 Are you a troll? This is not something to be quoted by anybody serious. Andrew referred to well-known weaknesses in cryptoloop, and when I inquired it turned out that what he referred to were properties of cryptoloop and dm-crypt alike, so that his remarks that started that discussion were misguided. Of course people may prefer dm-crypt or cryptoloop or loop-aes, just like people prefer ide-cd or ide-scsi. I have not yet seen a valid reason to deprecate one of these three very soon. Andries - 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 2.6.11.1
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote: > Here's the list of things which we might choose to put into 2.6.11.2. ... > nfsd--exportfs-reduce-stack-usage.patch ... Different people want different things with our 2.6.x.y. I would hope that criteria include (i) patch is obvious, and (ii) patch fixes an embarrassing flaw. I see no reason to include random small improvements. (Always some of these small improvements will be a mistake, so, in .y, when something is not really broken, don't fix it. Maybe people were actually seeing stack overflows here?) Andries >> From: NeilBrown <[EMAIL PROTECTED]> >> >> find_exported_dentry() declares >>char nbuf[NAME_MAX+1]; >> in 2 separate places, and gcc allocates space on the stack for both >> of them. Having just one of them will suffice, if we can put put >> with its scope. >> >> Reduces function stack usage on x86-32 from 0x230 to 0x130. - 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 2.6.11.1
On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote: Here's the list of things which we might choose to put into 2.6.11.2. ... nfsd--exportfs-reduce-stack-usage.patch ... Different people want different things with our 2.6.x.y. I would hope that criteria include (i) patch is obvious, and (ii) patch fixes an embarrassing flaw. I see no reason to include random small improvements. (Always some of these small improvements will be a mistake, so, in .y, when something is not really broken, don't fix it. Maybe people were actually seeing stack overflows here?) Andries From: NeilBrown [EMAIL PROTECTED] find_exported_dentry() declares char nbuf[NAME_MAX+1]; in 2 separate places, and gcc allocates space on the stack for both of them. Having just one of them will suffice, if we can put put with its scope. Reduces function stack usage on x86-32 from 0x230 to 0x130. - 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: RFD: Kernel release numbering
Ha - a nice big thread. Issues include trivial fixes, testing, and API stability. - About trivial fixes: davem: the day Linus releases we always get a pile of "missing MODULE_EXPORT()" type bug reports that are one liner fixes. davej: So what was broken with the 2.6.8.1 type of release ? akpm: But that _is_ a branch I think we all like the 2.6.8.1 model. davej: The only question in my mind is 'how critical does a bug have to be to justify a .y release'. I think that is the wrong question. The question should be 'how trivial should a fix be to be admissible in a .y release'. If something is important but nonobvious, it should cause earlier release of 2.6.x+1. No regressions in 2.6.x.y. - About testing: users do not test p.q.r-suffix, they just test p.q.r Solution: Release early, release often. No silly odd/even games. jgarzik: I would prefer a weekly snapshot as the release - API stability: Stable series like 2.0, 2.2, 2.4 try to maintain the guarantee that user-visible APIs do not change. That goal has disappeared, meaning that anything might break when one upgrades from 2.6.14 to 2.6.16. This is one of the big disadvantages of the new 2.6 way. - A separate twig is that of when to call a release 'stable'. Since there is no good way to predict, the solution is 'wait and see'. 'Stable' also depends on the type of use. It is easier to leave construction of stable kernels to separate people and trees. With some delay they can have the benefit of hindsight. Andries - 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: RFD: Kernel release numbering
Ha - a nice big thread. Issues include trivial fixes, testing, and API stability. - About trivial fixes: davem: the day Linus releases we always get a pile of missing MODULE_EXPORT() type bug reports that are one liner fixes. davej: So what was broken with the 2.6.8.1 type of release ? akpm: But that _is_ a branch I think we all like the 2.6.8.1 model. davej: The only question in my mind is 'how critical does a bug have to be to justify a .y release'. I think that is the wrong question. The question should be 'how trivial should a fix be to be admissible in a .y release'. If something is important but nonobvious, it should cause earlier release of 2.6.x+1. No regressions in 2.6.x.y. - About testing: users do not test p.q.r-suffix, they just test p.q.r Solution: Release early, release often. No silly odd/even games. jgarzik: I would prefer a weekly snapshot as the release - API stability: Stable series like 2.0, 2.2, 2.4 try to maintain the guarantee that user-visible APIs do not change. That goal has disappeared, meaning that anything might break when one upgrades from 2.6.14 to 2.6.16. This is one of the big disadvantages of the new 2.6 way. - A separate twig is that of when to call a release 'stable'. Since there is no good way to predict, the solution is 'wait and see'. 'Stable' also depends on the type of use. It is easier to leave construction of stable kernels to separate people and trees. With some delay they can have the benefit of hindsight. Andries - 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] remove dead cyrix/centaur mtrr init code
On Wed, Mar 02, 2005 at 01:45:43PM +, Alan Cox wrote:
> On Mer, 2005-03-02 at 08:02, Dave Jones wrote:
> > If there are any of them still being used out there, I'd be even
> > more surprised if they're running 2.6. Then again, there are
> > probably loonies out there running it on 386/486's. 8-)
>
> I have one here running 2.4 still. I can test a 2.6 fix for the mtrr
> init happily enough.
Good. If I understand things correctly - you or davej or someone will
correct me otherwise - failing to initialise mtrr does not break anything,
it would just mean slower access to certain kinds of memory for certain
kinds of access patterns. (Would you test using an X benchmark?)
Below roughly speaking the same patch as before, but with calls
to the cyrix and centaur mtrr init routines inserted.
Andries
-
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/centaur.c
b/arch/i386/kernel/cpu/mtrr/centaur.c
--- a/arch/i386/kernel/cpu/mtrr/centaur.c 2003-12-18 03:58:38.0
+0100
+++ b/arch/i386/kernel/cpu/mtrr/centaur.c 2005-03-02 23:22:10.0
+0100
@@ -86,6 +86,7 @@ static void centaur_set_mcr(unsigned int
centaur_mcr[reg].low = low;
wrmsr(MSR_IDT_MCR0 + reg, low, high);
}
+
/*
* Initialise the later (saner) Winchip MCR variant. In this version
* the BIOS can pass us the registers it has used (but not their values)
@@ -168,7 +169,7 @@ centaur_mcr0_init(void)
* Initialise Winchip series MCR registers
*/
-static void __init
+void __init
centaur_mcr_init(void)
{
struct set_mtrr_context ctxt;
@@ -203,7 +204,6 @@ static int centaur_validate_add_page(uns
static struct mtrr_ops centaur_mtrr_ops = {
.vendor= X86_VENDOR_CENTAUR,
- .init = centaur_mcr_init,
.set = centaur_set_mcr,
.get = centaur_get_mcr,
.get_free_region = centaur_get_free_region,
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/cyrix.c
b/arch/i386/kernel/cpu/mtrr/cyrix.c
--- a/arch/i386/kernel/cpu/mtrr/cyrix.c 2003-12-18 03:58:56.0 +0100
+++ b/arch/i386/kernel/cpu/mtrr/cyrix.c 2005-03-02 23:22:40.0 +0100
@@ -218,12 +218,12 @@ typedef struct {
mtrr_type type;
} arr_state_t;
-arr_state_t arr_state[8] __initdata = {
+static arr_state_t arr_state[8] __initdata = {
{0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL},
{0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}
};
-unsigned char ccr_state[7] __initdata = { 0, 0, 0, 0, 0, 0, 0 };
+static unsigned char ccr_state[7] __initdata = { 0, 0, 0, 0, 0, 0, 0 };
static void cyrix_set_all(void)
{
@@ -257,7 +257,7 @@ static void cyrix_set_all(void)
* - (maybe) disable ARR3
* Just to be sure, we enable ARR usage by the processor (CCR5 bit 5 set)
*/
-static void __init
+void __init
cyrix_arr_init(void)
{
struct set_mtrr_context ctxt;
@@ -344,7 +344,6 @@ cyrix_arr_init(void)
static struct mtrr_ops cyrix_mtrr_ops = {
.vendor= X86_VENDOR_CYRIX,
- .init = cyrix_arr_init,
.set_all = cyrix_set_all,
.set = cyrix_set_arr,
.get = cyrix_get_arr,
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/generic.c
b/arch/i386/kernel/cpu/mtrr/generic.c
--- a/arch/i386/kernel/cpu/mtrr/generic.c 2005-03-02 20:54:48.0
+0100
+++ b/arch/i386/kernel/cpu/mtrr/generic.c 2005-03-02 20:56:19.0
+0100
@@ -19,8 +19,7 @@ struct mtrr_state {
};
static unsigned long smp_changes_mask;
-struct mtrr_state mtrr_state = {};
-
+static struct mtrr_state mtrr_state = {};
/* Get the MSR pair relating to a var range */
static void __init
@@ -383,7 +382,7 @@ int generic_validate_add_page(unsigned l
}
-int generic_have_wrcomb(void)
+static int generic_have_wrcomb(void)
{
unsigned long config, dummy;
rdmsr(MTRRcap_MSR, config, dummy);
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/main.c
b/arch/i386/kernel/cpu/mtrr/main.c
--- a/arch/i386/kernel/cpu/mtrr/main.c 2004-12-29 03:39:42.0 +0100
+++ b/arch/i386/kernel/cpu/mtrr/main.c 2005-03-02 23:21:46.0 +0100
@@ -57,10 +57,6 @@ static struct mtrr_ops * mtrr_ops[X86_VE
struct mtrr_ops * mtrr_if = NULL;
-__initdata char *mtrr_if_name[] = {
-"none", "Intel", "AMD K6", "Cyrix ARR", "Centaur MCR"
-};
-
static void set_mtrr(unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type);
@@ -100,7 +96,7 @@ static int have_wrcomb(void)
}
/* This function returns the number of variable MTRRs */
-void __init set_num_var_ranges(void)
+static void __init set_num_var_ranges(void)
{
unsigned long config = 0, dummy;
@@ -526,6 +522,8 @@ EXPORT_SYMBOL(mtrr_del);
* These should be called implicitly, but we can't yet until all the initcall
* stuff is done...
*/
+extern void
Re: [PATCH] remove dead cyrix/centaur mtrr init code
On Wed, Mar 02, 2005 at 01:45:43PM +, Alan Cox wrote:
On Mer, 2005-03-02 at 08:02, Dave Jones wrote:
If there are any of them still being used out there, I'd be even
more surprised if they're running 2.6. Then again, there are
probably loonies out there running it on 386/486's. 8-)
I have one here running 2.4 still. I can test a 2.6 fix for the mtrr
init happily enough.
Good. If I understand things correctly - you or davej or someone will
correct me otherwise - failing to initialise mtrr does not break anything,
it would just mean slower access to certain kinds of memory for certain
kinds of access patterns. (Would you test using an X benchmark?)
Below roughly speaking the same patch as before, but with calls
to the cyrix and centaur mtrr init routines inserted.
Andries
-
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/centaur.c
b/arch/i386/kernel/cpu/mtrr/centaur.c
--- a/arch/i386/kernel/cpu/mtrr/centaur.c 2003-12-18 03:58:38.0
+0100
+++ b/arch/i386/kernel/cpu/mtrr/centaur.c 2005-03-02 23:22:10.0
+0100
@@ -86,6 +86,7 @@ static void centaur_set_mcr(unsigned int
centaur_mcr[reg].low = low;
wrmsr(MSR_IDT_MCR0 + reg, low, high);
}
+
/*
* Initialise the later (saner) Winchip MCR variant. In this version
* the BIOS can pass us the registers it has used (but not their values)
@@ -168,7 +169,7 @@ centaur_mcr0_init(void)
* Initialise Winchip series MCR registers
*/
-static void __init
+void __init
centaur_mcr_init(void)
{
struct set_mtrr_context ctxt;
@@ -203,7 +204,6 @@ static int centaur_validate_add_page(uns
static struct mtrr_ops centaur_mtrr_ops = {
.vendor= X86_VENDOR_CENTAUR,
- .init = centaur_mcr_init,
.set = centaur_set_mcr,
.get = centaur_get_mcr,
.get_free_region = centaur_get_free_region,
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/cyrix.c
b/arch/i386/kernel/cpu/mtrr/cyrix.c
--- a/arch/i386/kernel/cpu/mtrr/cyrix.c 2003-12-18 03:58:56.0 +0100
+++ b/arch/i386/kernel/cpu/mtrr/cyrix.c 2005-03-02 23:22:40.0 +0100
@@ -218,12 +218,12 @@ typedef struct {
mtrr_type type;
} arr_state_t;
-arr_state_t arr_state[8] __initdata = {
+static arr_state_t arr_state[8] __initdata = {
{0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL},
{0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}
};
-unsigned char ccr_state[7] __initdata = { 0, 0, 0, 0, 0, 0, 0 };
+static unsigned char ccr_state[7] __initdata = { 0, 0, 0, 0, 0, 0, 0 };
static void cyrix_set_all(void)
{
@@ -257,7 +257,7 @@ static void cyrix_set_all(void)
* - (maybe) disable ARR3
* Just to be sure, we enable ARR usage by the processor (CCR5 bit 5 set)
*/
-static void __init
+void __init
cyrix_arr_init(void)
{
struct set_mtrr_context ctxt;
@@ -344,7 +344,6 @@ cyrix_arr_init(void)
static struct mtrr_ops cyrix_mtrr_ops = {
.vendor= X86_VENDOR_CYRIX,
- .init = cyrix_arr_init,
.set_all = cyrix_set_all,
.set = cyrix_set_arr,
.get = cyrix_get_arr,
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/generic.c
b/arch/i386/kernel/cpu/mtrr/generic.c
--- a/arch/i386/kernel/cpu/mtrr/generic.c 2005-03-02 20:54:48.0
+0100
+++ b/arch/i386/kernel/cpu/mtrr/generic.c 2005-03-02 20:56:19.0
+0100
@@ -19,8 +19,7 @@ struct mtrr_state {
};
static unsigned long smp_changes_mask;
-struct mtrr_state mtrr_state = {};
-
+static struct mtrr_state mtrr_state = {};
/* Get the MSR pair relating to a var range */
static void __init
@@ -383,7 +382,7 @@ int generic_validate_add_page(unsigned l
}
-int generic_have_wrcomb(void)
+static int generic_have_wrcomb(void)
{
unsigned long config, dummy;
rdmsr(MTRRcap_MSR, config, dummy);
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/main.c
b/arch/i386/kernel/cpu/mtrr/main.c
--- a/arch/i386/kernel/cpu/mtrr/main.c 2004-12-29 03:39:42.0 +0100
+++ b/arch/i386/kernel/cpu/mtrr/main.c 2005-03-02 23:21:46.0 +0100
@@ -57,10 +57,6 @@ static struct mtrr_ops * mtrr_ops[X86_VE
struct mtrr_ops * mtrr_if = NULL;
-__initdata char *mtrr_if_name[] = {
-none, Intel, AMD K6, Cyrix ARR, Centaur MCR
-};
-
static void set_mtrr(unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type);
@@ -100,7 +96,7 @@ static int have_wrcomb(void)
}
/* This function returns the number of variable MTRRs */
-void __init set_num_var_ranges(void)
+static void __init set_num_var_ranges(void)
{
unsigned long config = 0, dummy;
@@ -526,6 +522,8 @@ EXPORT_SYMBOL(mtrr_del);
* These should be called implicitly, but we can't yet until all the initcall
* stuff is done...
*/
+extern void centaur_mcr_init(void);
+extern
Re: [PATCH] remove dead cyrix/centaur mtrr init code
On Tue, Mar 01, 2005 at 11:52:44PM +, Alan Cox wrote: > On Llu, 2005-02-28 at 19:20, Andries Brouwer wrote: > > One such case is the mtrr code, where struct mtrr_ops has an > > init field pointing at __init functions. Unless I overlook > > something, this case may be easy to settle, since the .init > > field is never used. > > The failure to invoke the ->init operator appears to be the bug. > The centaur code definitely wants the mcr init function to be called. Yes, I expected that to be the answer. Therefore #if 0 instead of deleting. But if calling ->init() is needed, and it has not been done the past three years, the question arises whether there are any users. Andries - 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] remove dead cyrix/centaur mtrr init code
On Tue, Mar 01, 2005 at 11:52:44PM +, Alan Cox wrote: On Llu, 2005-02-28 at 19:20, Andries Brouwer wrote: One such case is the mtrr code, where struct mtrr_ops has an init field pointing at __init functions. Unless I overlook something, this case may be easy to settle, since the .init field is never used. The failure to invoke the -init operator appears to be the bug. The centaur code definitely wants the mcr init function to be called. Yes, I expected that to be the answer. Therefore #if 0 instead of deleting. But if calling -init() is needed, and it has not been done the past three years, the question arises whether there are any users. Andries - 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] remove dead cyrix/centaur mtrr init code
On Mon, Feb 28, 2005 at 08:35:29PM +0100, Adrian Bunk wrote: > Hi Andries, > > your patch has many overlappings with a patch of mine aleady in -mm > (both none of the two patches is a subset of the other one). > > Nowadays, working against -mm often avoids duplicate work. > > cu > Adrian As far as I am concerned this doesnt matter so much. This is very trivial work, and only little time is wasted in case of duplication. It is unavoidable. (For example, looking at the detect functions of scsi drivers I happened to come across pas16.c and did a largish cleanup. Hesitate a bit submitting the results, since the driver showed some signs of bitrot - maybe nobody has used it for years - if someone uses pas16, please tell me - let me cc linux-scsi - but today you submit a little patch on pas16.) Andries - 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] remove dead cyrix/centaur mtrr init code
There are several cases where __init function pointers are
stored in a general purpose struct. For example, a SCSI
template may contain a __init detect function.
Have not yet thought of an elegant way to avoid this.
One such case is the mtrr code, where struct mtrr_ops has an
init field pointing at __init functions. Unless I overlook
something, this case may be easy to settle, since the .init
field is never used.
The patch below comments out the declaration and initialisation
of the .init field of struct mtrr_ops, and puts #if 0 ... #endif
around the centaur_mcr_init() and cyrix_arr_init() code.
Simultaneously a number of variables are made static.
Andries
-
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/centaur.c
b/arch/i386/kernel/cpu/mtrr/centaur.c
--- a/arch/i386/kernel/cpu/mtrr/centaur.c 2003-12-18 03:58:38.0
+0100
+++ b/arch/i386/kernel/cpu/mtrr/centaur.c 2005-02-28 20:21:05.0
+0100
@@ -86,6 +86,8 @@ static void centaur_set_mcr(unsigned int
centaur_mcr[reg].low = low;
wrmsr(MSR_IDT_MCR0 + reg, low, high);
}
+
+#if 0
/*
* Initialise the later (saner) Winchip MCR variant. In this version
* the BIOS can pass us the registers it has used (but not their values)
@@ -183,6 +185,7 @@ centaur_mcr_init(void)
set_mtrr_done();
}
+#endif
static int centaur_validate_add_page(unsigned long base,
unsigned long size, unsigned int type)
@@ -203,7 +206,7 @@ static int centaur_validate_add_page(uns
static struct mtrr_ops centaur_mtrr_ops = {
.vendor= X86_VENDOR_CENTAUR,
- .init = centaur_mcr_init,
+// .init = centaur_mcr_init,
.set = centaur_set_mcr,
.get = centaur_get_mcr,
.get_free_region = centaur_get_free_region,
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/cyrix.c
b/arch/i386/kernel/cpu/mtrr/cyrix.c
--- a/arch/i386/kernel/cpu/mtrr/cyrix.c 2003-12-18 03:58:56.0 +0100
+++ b/arch/i386/kernel/cpu/mtrr/cyrix.c 2005-02-28 20:19:25.0 +0100
@@ -218,12 +218,12 @@ typedef struct {
mtrr_type type;
} arr_state_t;
-arr_state_t arr_state[8] __initdata = {
+static arr_state_t arr_state[8] __initdata = {
{0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL},
{0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}
};
-unsigned char ccr_state[7] __initdata = { 0, 0, 0, 0, 0, 0, 0 };
+static unsigned char ccr_state[7] __initdata = { 0, 0, 0, 0, 0, 0, 0 };
static void cyrix_set_all(void)
{
@@ -243,6 +243,7 @@ static void cyrix_set_all(void)
post_set();
}
+#if 0
/*
* On Cyrix 6x86(MX) and M II the ARR3 is special: it has connection
* with the SMM (System Management Mode) mode. So we need the following:
@@ -341,10 +342,11 @@ cyrix_arr_init(void)
if (ccrc[6])
printk(KERN_INFO "mtrr: ARR3 was write protected,
unprotected\n");
}
+#endif
static struct mtrr_ops cyrix_mtrr_ops = {
.vendor= X86_VENDOR_CYRIX,
- .init = cyrix_arr_init,
+// .init = cyrix_arr_init,
.set_all = cyrix_set_all,
.set = cyrix_set_arr,
.get = cyrix_get_arr,
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/generic.c
b/arch/i386/kernel/cpu/mtrr/generic.c
--- a/arch/i386/kernel/cpu/mtrr/generic.c 2005-02-26 12:13:28.0
+0100
+++ b/arch/i386/kernel/cpu/mtrr/generic.c 2005-02-28 20:19:25.0
+0100
@@ -19,8 +19,7 @@ struct mtrr_state {
};
static unsigned long smp_changes_mask;
-struct mtrr_state mtrr_state = {};
-
+static struct mtrr_state mtrr_state = {};
/* Get the MSR pair relating to a var range */
static void __init
@@ -383,7 +382,7 @@ int generic_validate_add_page(unsigned l
}
-int generic_have_wrcomb(void)
+static int generic_have_wrcomb(void)
{
unsigned long config, dummy;
rdmsr(MTRRcap_MSR, config, dummy);
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/main.c
b/arch/i386/kernel/cpu/mtrr/main.c
--- a/arch/i386/kernel/cpu/mtrr/main.c 2004-12-29 03:39:42.0 +0100
+++ b/arch/i386/kernel/cpu/mtrr/main.c 2005-02-28 20:19:25.0 +0100
@@ -57,10 +57,6 @@ static struct mtrr_ops * mtrr_ops[X86_VE
struct mtrr_ops * mtrr_if = NULL;
-__initdata char *mtrr_if_name[] = {
-"none", "Intel", "AMD K6", "Cyrix ARR", "Centaur MCR"
-};
-
static void set_mtrr(unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type);
@@ -100,7 +96,7 @@ static int have_wrcomb(void)
}
/* This function returns the number of variable MTRRs */
-void __init set_num_var_ranges(void)
+static void __init set_num_var_ranges(void)
{
unsigned long config = 0, dummy;
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/mtrr.h
b/arch/i386/kernel/cpu/mtrr/mtrr.h
---
Re: [patch 2/2] drivers/chat/vt.c: remove unnecessary code
On Mon, Feb 28, 2005 at 01:55:28PM +0100, [EMAIL PROTECTED] wrote: > Avoid changing the state of the console two times in some cases. A bad change for several reasons. (i) more object code is generated (ii) the code is slower (iii) you change something Straight line code is cheap, jumps are expensive. Replacing an assignment by a jump is not an improvement. But far worse: this is a purposeless microoptimization. At least one out of every hundred trivial patches is broken. Thus, a stream of trivial changes will only break the kernel, for no gain. Andries - 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/2] drivers/chat/vt.c: remove unnecessary code
On Mon, Feb 28, 2005 at 01:55:28PM +0100, [EMAIL PROTECTED] wrote: Avoid changing the state of the console two times in some cases. A bad change for several reasons. (i) more object code is generated (ii) the code is slower (iii) you change something Straight line code is cheap, jumps are expensive. Replacing an assignment by a jump is not an improvement. But far worse: this is a purposeless microoptimization. At least one out of every hundred trivial patches is broken. Thus, a stream of trivial changes will only break the kernel, for no gain. Andries - 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] remove dead cyrix/centaur mtrr init code
There are several cases where __init function pointers are
stored in a general purpose struct. For example, a SCSI
template may contain a __init detect function.
Have not yet thought of an elegant way to avoid this.
One such case is the mtrr code, where struct mtrr_ops has an
init field pointing at __init functions. Unless I overlook
something, this case may be easy to settle, since the .init
field is never used.
The patch below comments out the declaration and initialisation
of the .init field of struct mtrr_ops, and puts #if 0 ... #endif
around the centaur_mcr_init() and cyrix_arr_init() code.
Simultaneously a number of variables are made static.
Andries
-
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/centaur.c
b/arch/i386/kernel/cpu/mtrr/centaur.c
--- a/arch/i386/kernel/cpu/mtrr/centaur.c 2003-12-18 03:58:38.0
+0100
+++ b/arch/i386/kernel/cpu/mtrr/centaur.c 2005-02-28 20:21:05.0
+0100
@@ -86,6 +86,8 @@ static void centaur_set_mcr(unsigned int
centaur_mcr[reg].low = low;
wrmsr(MSR_IDT_MCR0 + reg, low, high);
}
+
+#if 0
/*
* Initialise the later (saner) Winchip MCR variant. In this version
* the BIOS can pass us the registers it has used (but not their values)
@@ -183,6 +185,7 @@ centaur_mcr_init(void)
set_mtrr_done(ctxt);
}
+#endif
static int centaur_validate_add_page(unsigned long base,
unsigned long size, unsigned int type)
@@ -203,7 +206,7 @@ static int centaur_validate_add_page(uns
static struct mtrr_ops centaur_mtrr_ops = {
.vendor= X86_VENDOR_CENTAUR,
- .init = centaur_mcr_init,
+// .init = centaur_mcr_init,
.set = centaur_set_mcr,
.get = centaur_get_mcr,
.get_free_region = centaur_get_free_region,
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/cyrix.c
b/arch/i386/kernel/cpu/mtrr/cyrix.c
--- a/arch/i386/kernel/cpu/mtrr/cyrix.c 2003-12-18 03:58:56.0 +0100
+++ b/arch/i386/kernel/cpu/mtrr/cyrix.c 2005-02-28 20:19:25.0 +0100
@@ -218,12 +218,12 @@ typedef struct {
mtrr_type type;
} arr_state_t;
-arr_state_t arr_state[8] __initdata = {
+static arr_state_t arr_state[8] __initdata = {
{0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL},
{0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}, {0UL, 0UL, 0UL}
};
-unsigned char ccr_state[7] __initdata = { 0, 0, 0, 0, 0, 0, 0 };
+static unsigned char ccr_state[7] __initdata = { 0, 0, 0, 0, 0, 0, 0 };
static void cyrix_set_all(void)
{
@@ -243,6 +243,7 @@ static void cyrix_set_all(void)
post_set();
}
+#if 0
/*
* On Cyrix 6x86(MX) and M II the ARR3 is special: it has connection
* with the SMM (System Management Mode) mode. So we need the following:
@@ -341,10 +342,11 @@ cyrix_arr_init(void)
if (ccrc[6])
printk(KERN_INFO mtrr: ARR3 was write protected,
unprotected\n);
}
+#endif
static struct mtrr_ops cyrix_mtrr_ops = {
.vendor= X86_VENDOR_CYRIX,
- .init = cyrix_arr_init,
+// .init = cyrix_arr_init,
.set_all = cyrix_set_all,
.set = cyrix_set_arr,
.get = cyrix_get_arr,
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/generic.c
b/arch/i386/kernel/cpu/mtrr/generic.c
--- a/arch/i386/kernel/cpu/mtrr/generic.c 2005-02-26 12:13:28.0
+0100
+++ b/arch/i386/kernel/cpu/mtrr/generic.c 2005-02-28 20:19:25.0
+0100
@@ -19,8 +19,7 @@ struct mtrr_state {
};
static unsigned long smp_changes_mask;
-struct mtrr_state mtrr_state = {};
-
+static struct mtrr_state mtrr_state = {};
/* Get the MSR pair relating to a var range */
static void __init
@@ -383,7 +382,7 @@ int generic_validate_add_page(unsigned l
}
-int generic_have_wrcomb(void)
+static int generic_have_wrcomb(void)
{
unsigned long config, dummy;
rdmsr(MTRRcap_MSR, config, dummy);
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/main.c
b/arch/i386/kernel/cpu/mtrr/main.c
--- a/arch/i386/kernel/cpu/mtrr/main.c 2004-12-29 03:39:42.0 +0100
+++ b/arch/i386/kernel/cpu/mtrr/main.c 2005-02-28 20:19:25.0 +0100
@@ -57,10 +57,6 @@ static struct mtrr_ops * mtrr_ops[X86_VE
struct mtrr_ops * mtrr_if = NULL;
-__initdata char *mtrr_if_name[] = {
-none, Intel, AMD K6, Cyrix ARR, Centaur MCR
-};
-
static void set_mtrr(unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type);
@@ -100,7 +96,7 @@ static int have_wrcomb(void)
}
/* This function returns the number of variable MTRRs */
-void __init set_num_var_ranges(void)
+static void __init set_num_var_ranges(void)
{
unsigned long config = 0, dummy;
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/cpu/mtrr/mtrr.h
b/arch/i386/kernel/cpu/mtrr/mtrr.h
---
Re: [PATCH] remove dead cyrix/centaur mtrr init code
On Mon, Feb 28, 2005 at 08:35:29PM +0100, Adrian Bunk wrote: Hi Andries, your patch has many overlappings with a patch of mine aleady in -mm (both none of the two patches is a subset of the other one). Nowadays, working against -mm often avoids duplicate work. cu Adrian As far as I am concerned this doesnt matter so much. This is very trivial work, and only little time is wasted in case of duplication. It is unavoidable. (For example, looking at the detect functions of scsi drivers I happened to come across pas16.c and did a largish cleanup. Hesitate a bit submitting the results, since the driver showed some signs of bitrot - maybe nobody has used it for years - if someone uses pas16, please tell me - let me cc linux-scsi - but today you submit a little patch on pas16.) Andries - 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/
remove include/sound/yss225.h
The file include/sound/yss225.h is unused.
It is more or less identical to sound/oss/yss225.h,
used by sound/oss/wavfront.c.
# rm include/sound/yss225.h
Andries
(Maybe this file is a remains from an attempt to consolidate
sound/oss/yss225.c and sound/isa/wavefront/wavefront_fx.c -
it is true that that code duplication should be eliminated,
but the identifiers used ("page_zero" etc.) are unsuitable
as globals anyway.)
-
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/
remove include/sound/yss225.h
The file include/sound/yss225.h is unused. It is more or less identical to sound/oss/yss225.h, used by sound/oss/wavfront.c. # rm include/sound/yss225.h Andries (Maybe this file is a remains from an attempt to consolidate sound/oss/yss225.c and sound/isa/wavefront/wavefront_fx.c - it is true that that code duplication should be eliminated, but the identifiers used (page_zero etc.) are unsuitable as globals anyway.) - 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] config option for default loglevel
On Sun, Feb 27, 2005 at 03:04:31AM +0100, Matthias Kunze wrote: +config DEFAULT_CONSOLE_LOGLEVEL You do not want to add yet another config option. Config options are used to select or deselect major subsystems, or support for specific hardware. Not to tweak variables. Adding more config variables is not an improvement. There are many ways to set the loglevel from user space. You add one on the command line - maybe useful in case more output is needed when the kernel crashes in early boot. I see no justification for DEFAULT_CONSOLE_LOGLEVEL. Andries - 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] partitions/msdos.c
On Sun, Feb 27, 2005 at 01:47:43AM +0100, Uwe Bonnes wrote: > on a Suse 9.2 System with Suse Hotplug, the phantom partition was somehow > recognized as Reiserfs, and then the Hotplug mechanism trying to mount the > bogus partition as a Reiser Filesystem ended in an Oops... Always report the oops. It is well-known that mounting garbage may crash the kernel. Earlier the reply was "don't do that then". Nowadays we have more layers of software trying to probe and do automatic things, and the kernel must survive attempts to mount garbage. Andries - 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] partitions/msdos.c
On Sat, Feb 26, 2005 at 03:46:03PM -0800, Linus Torvalds wrote:
> We should probably do the same for the
> extended partition case, just to be consistent.
True.
diff -uprN -X /linux/dontdiff a/fs/partitions/msdos.c b/fs/partitions/msdos.c
--- a/fs/partitions/msdos.c 2004-12-29 03:39:55.0 +0100
+++ b/fs/partitions/msdos.c 2005-02-27 01:10:06.0 +0100
@@ -114,6 +114,9 @@ parse_extended(struct parsed_partitions
*/
for (i=0; i<4; i++, p++) {
u32 offs, size, next;
+
+ if (SYS_IND(p) == 0)
+ continue;
if (!NR_SECTS(p) || is_extended_partition(p))
continue;
@@ -430,6 +433,8 @@ int msdos_partition(struct parsed_partit
for (slot = 1 ; slot <= 4 ; slot++, p++) {
u32 start = START_SECT(p)*sector_size;
u32 size = NR_SECTS(p)*sector_size;
+ if (SYS_IND(p) == 0)
+ continue;
if (!size)
continue;
if (is_extended_partition(p)) {
-
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] partitions/msdos.c
On Sat, Feb 26, 2005 at 03:12:28PM -0800, Linus Torvalds wrote: > > The default fdisk will assign type 83 to a newly created partition. > > Ok. Is that a "it has done so for the last 5 years" thing? The last twelve years. > > (About type 0: DOS has used type 0 as definition of unused. It is not > > bad if Linux uses DOS-conventions for a DOS-type partition table.) > > Agreed. At the same time, I could well imagine that some people might use > such a type exactly to make DOS ignore it (but I assume the same is true > of the regular 0x83 type too, so maybe I'm just being difficult). > > There's certainly a good argument for fixing a known problem (Uwe) and a > small enough risk of it breaking anything else. Yes. Andries (Concerning the "size" version: it occurred to me that there is one very minor objection: For extended partitions so far the size did not normally play a role. Only the starting sector was significant. If, at some moment we decide also to check the size, then a weaker check, namely only checking for non-extended partitions, might be better at first.) (Yes, disk capacity is not always known - see e.g. ll_rw_blk.c: /* Test device or partition size, when known. */ See also sd.c, with the strange sdkp->capacity = 0x20; /* 1 GB - random */ In such cases we just access the blocks user space tells us to access.) - 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] partitions/msdos.c
On Sat, Feb 26, 2005 at 02:28:45PM -0800, Linus Torvalds wrote: > Would it not make more sense to just sanity-check the size itself, and > throw it out if the partition size (plus start) is bigger than the disk > size? I don't mind. > There might well be people use use partition type 0, just because they > just never _set_ the partition type.. I don't think Linux has ever cared > about any type except for the "extended partition" type, so checking for > zero doesn't seem very safe.. The default fdisk will assign type 83 to a newly created partition. One has to change it by hand to 0. So, I do not think testing against 0 is so bad. A heuristic, You give another heuristic. Probably there will be a point in time where we need both. (About type 0: DOS has used type 0 as definition of unused. It is not bad if Linux uses DOS-conventions for a DOS-type partition table.) Andries - 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] partitions/msdos.c
A well-known kernel bug is that it guesses at the partition type
and the partitions on any disk it encounters. This is bad because
needless I/O is done, slowing down the boot, sometimes quite a lot,
especially when I/O errors occur. And it is bad because sometimes
we guess wrong.
In other words, we need the user space command `partition',
where "partition -t dos /dev/sda" reads a DOS-type partition
table. (And "partition /dev/sda" tries all known heuristics
to decide what type of partitioning might be present.)
The two variants are: (i) partition tells the kernel
to do the partition table reading, and (ii) partition uses partx
to read the partition table and tells the kernel one-by-one
about the partitions found this way.
Since this is a fundamental change, a long transition period
is needed, and that period could start with a kernel boot parameter
telling the kernel not to do partition table parsing on a particular
disk, or a particular type of disks, or all disks.
This could have been the intro to a patch doing that, but is not.
(It is just an RFC.)
The tiny patch below prompted the above - it was suggested by Uwe Bonnes
who encountered USB devices without partition table where our present
heuristics did not suffice to stop partition table parsing.
It causes the kernel to ignore partitions of type 0. A band-aid.
I think nobody uses such partitions seriously, but nevertheless this
should probably live in -mm for a while to see if anybody complains.
Andries
diff -uprN -X /linux/dontdiff a/fs/partitions/msdos.c b/fs/partitions/msdos.c
--- a/fs/partitions/msdos.c 2004-12-29 03:39:55.0 +0100
+++ b/fs/partitions/msdos.c 2005-02-26 22:21:06.0 +0100
@@ -430,6 +430,8 @@ int msdos_partition(struct parsed_partit
for (slot = 1 ; slot <= 4 ; slot++, p++) {
u32 start = START_SECT(p)*sector_size;
u32 size = NR_SECTS(p)*sector_size;
+ if (SYS_IND(p) == 0)
+ continue;
if (!size)
continue;
if (is_extended_partition(p)) {
-
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] more apic.c
setup_APIC_timer is only called in __init context and uses __initdata
Andries
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/apic.c
b/arch/i386/kernel/apic.c
--- a/arch/i386/kernel/apic.c 2005-02-26 12:13:28.0 +0100
+++ b/arch/i386/kernel/apic.c 2005-02-26 16:13:21.0 +0100
@@ -930,7 +930,7 @@ void __setup_APIC_LVTT(unsigned int cloc
apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
}
-static void setup_APIC_timer(unsigned int clocks)
+static void __init setup_APIC_timer(unsigned int clocks)
{
unsigned long flags;
-
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] __initdata in apic.c
wait_timer_tick refers to the __init functions wait_8254_wraparound or wait_hpet_tick, hence must be __initdata. Andries diff -uprN -X /linux/dontdiff a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c --- a/arch/i386/kernel/apic.c 2005-02-26 12:13:28.0 +0100 +++ b/arch/i386/kernel/apic.c 2005-02-26 15:59:17.0 +0100 @@ -894,7 +894,7 @@ static void __init wait_8254_wraparound( * Default initialization for 8254 timers. If we use other timers like HPET, * we override this later */ -void (*wait_timer_tick)(void) = wait_8254_wraparound; +void (*wait_timer_tick)(void) __initdata = wait_8254_wraparound; /* * This function sets up the local APIC timer, with a timeout of - 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] remove __initdata in scsi_devinfo.c
scsi_dev_flags is referred to in
module_param_string(dev_flags, scsi_dev_flags, sizeof(scsi_dev_flags), 0);
Andries
diff -uprN -X /linux/dontdiff a/drivers/scsi/scsi_devinfo.c
b/drivers/scsi/scsi_devinfo.c
--- a/drivers/scsi/scsi_devinfo.c 2004-12-29 03:39:47.0 +0100
+++ b/drivers/scsi/scsi_devinfo.c 2005-02-26 14:30:15.0 +0100
@@ -28,7 +28,7 @@ struct scsi_dev_info_list {
static const char spaces[] = ""; /* 16 of them */
static unsigned scsi_default_dev_flags;
static LIST_HEAD(scsi_dev_info_list);
-static __initdata char scsi_dev_flags[256];
+static char scsi_dev_flags[256];
/*
* scsi_static_device_list: deprecated list of devices that require
-
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] __init in cfq-iosched.c
cfq_init() calls __init cfq_slab_setup and hence must be __init itself
also made it static
Andries
diff -uprN -X /linux/dontdiff a/drivers/block/cfq-iosched.c
b/drivers/block/cfq-iosched.c
--- a/drivers/block/cfq-iosched.c 2005-02-26 12:13:29.0 +0100
+++ b/drivers/block/cfq-iosched.c 2005-02-26 14:18:00.0 +0100
@@ -1819,7 +1819,7 @@ static struct elevator_type iosched_cfq
.elevator_owner = THIS_MODULE,
};
-int cfq_init(void)
+static int __init cfq_init(void)
{
int ret;
-
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] __devinitdata in parport_pc
parport_init_mode is referred to in int __devinit sio_via_probe().
Andries
diff -uprN -X /linux/dontdiff a/drivers/parport/parport_pc.c
b/drivers/parport/parport_pc.c
--- a/drivers/parport/parport_pc.c 2005-02-26 12:13:30.0 +0100
+++ b/drivers/parport/parport_pc.c 2005-02-26 14:06:23.0 +0100
@@ -2488,7 +2488,7 @@ static int __devinit sio_ite_8872_probe
/* VIA 8231 support by Pavel Fedin <[EMAIL PROTECTED]>
based on VIA 686a support code by Jeff Garzik <[EMAIL PROTECTED]> */
-static int __initdata parport_init_mode = 0;
+static int __devinitdata parport_init_mode = 0;
/* Data for two known VIA chips */
static struct parport_pc_via_data via_686a_data __devinitdata = {
-
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] __devinitdata in parport_pc
parport_init_mode is referred to in int __devinit sio_via_probe().
Andries
diff -uprN -X /linux/dontdiff a/drivers/parport/parport_pc.c
b/drivers/parport/parport_pc.c
--- a/drivers/parport/parport_pc.c 2005-02-26 12:13:30.0 +0100
+++ b/drivers/parport/parport_pc.c 2005-02-26 14:06:23.0 +0100
@@ -2488,7 +2488,7 @@ static int __devinit sio_ite_8872_probe
/* VIA 8231 support by Pavel Fedin [EMAIL PROTECTED]
based on VIA 686a support code by Jeff Garzik [EMAIL PROTECTED] */
-static int __initdata parport_init_mode = 0;
+static int __devinitdata parport_init_mode = 0;
/* Data for two known VIA chips */
static struct parport_pc_via_data via_686a_data __devinitdata = {
-
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] __init in cfq-iosched.c
cfq_init() calls __init cfq_slab_setup and hence must be __init itself
also made it static
Andries
diff -uprN -X /linux/dontdiff a/drivers/block/cfq-iosched.c
b/drivers/block/cfq-iosched.c
--- a/drivers/block/cfq-iosched.c 2005-02-26 12:13:29.0 +0100
+++ b/drivers/block/cfq-iosched.c 2005-02-26 14:18:00.0 +0100
@@ -1819,7 +1819,7 @@ static struct elevator_type iosched_cfq
.elevator_owner = THIS_MODULE,
};
-int cfq_init(void)
+static int __init cfq_init(void)
{
int ret;
-
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] remove __initdata in scsi_devinfo.c
scsi_dev_flags is referred to in
module_param_string(dev_flags, scsi_dev_flags, sizeof(scsi_dev_flags), 0);
Andries
diff -uprN -X /linux/dontdiff a/drivers/scsi/scsi_devinfo.c
b/drivers/scsi/scsi_devinfo.c
--- a/drivers/scsi/scsi_devinfo.c 2004-12-29 03:39:47.0 +0100
+++ b/drivers/scsi/scsi_devinfo.c 2005-02-26 14:30:15.0 +0100
@@ -28,7 +28,7 @@ struct scsi_dev_info_list {
static const char spaces[] = ; /* 16 of them */
static unsigned scsi_default_dev_flags;
static LIST_HEAD(scsi_dev_info_list);
-static __initdata char scsi_dev_flags[256];
+static char scsi_dev_flags[256];
/*
* scsi_static_device_list: deprecated list of devices that require
-
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] __initdata in apic.c
wait_timer_tick refers to the __init functions wait_8254_wraparound or wait_hpet_tick, hence must be __initdata. Andries diff -uprN -X /linux/dontdiff a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c --- a/arch/i386/kernel/apic.c 2005-02-26 12:13:28.0 +0100 +++ b/arch/i386/kernel/apic.c 2005-02-26 15:59:17.0 +0100 @@ -894,7 +894,7 @@ static void __init wait_8254_wraparound( * Default initialization for 8254 timers. If we use other timers like HPET, * we override this later */ -void (*wait_timer_tick)(void) = wait_8254_wraparound; +void (*wait_timer_tick)(void) __initdata = wait_8254_wraparound; /* * This function sets up the local APIC timer, with a timeout of - 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] more apic.c
setup_APIC_timer is only called in __init context and uses __initdata
Andries
diff -uprN -X /linux/dontdiff a/arch/i386/kernel/apic.c
b/arch/i386/kernel/apic.c
--- a/arch/i386/kernel/apic.c 2005-02-26 12:13:28.0 +0100
+++ b/arch/i386/kernel/apic.c 2005-02-26 16:13:21.0 +0100
@@ -930,7 +930,7 @@ void __setup_APIC_LVTT(unsigned int cloc
apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
}
-static void setup_APIC_timer(unsigned int clocks)
+static void __init setup_APIC_timer(unsigned int clocks)
{
unsigned long flags;
-
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] partitions/msdos.c
A well-known kernel bug is that it guesses at the partition type
and the partitions on any disk it encounters. This is bad because
needless I/O is done, slowing down the boot, sometimes quite a lot,
especially when I/O errors occur. And it is bad because sometimes
we guess wrong.
In other words, we need the user space command `partition',
where partition -t dos /dev/sda reads a DOS-type partition
table. (And partition /dev/sda tries all known heuristics
to decide what type of partitioning might be present.)
The two variants are: (i) partition tells the kernel
to do the partition table reading, and (ii) partition uses partx
to read the partition table and tells the kernel one-by-one
about the partitions found this way.
Since this is a fundamental change, a long transition period
is needed, and that period could start with a kernel boot parameter
telling the kernel not to do partition table parsing on a particular
disk, or a particular type of disks, or all disks.
This could have been the intro to a patch doing that, but is not.
(It is just an RFC.)
The tiny patch below prompted the above - it was suggested by Uwe Bonnes
who encountered USB devices without partition table where our present
heuristics did not suffice to stop partition table parsing.
It causes the kernel to ignore partitions of type 0. A band-aid.
I think nobody uses such partitions seriously, but nevertheless this
should probably live in -mm for a while to see if anybody complains.
Andries
diff -uprN -X /linux/dontdiff a/fs/partitions/msdos.c b/fs/partitions/msdos.c
--- a/fs/partitions/msdos.c 2004-12-29 03:39:55.0 +0100
+++ b/fs/partitions/msdos.c 2005-02-26 22:21:06.0 +0100
@@ -430,6 +430,8 @@ int msdos_partition(struct parsed_partit
for (slot = 1 ; slot = 4 ; slot++, p++) {
u32 start = START_SECT(p)*sector_size;
u32 size = NR_SECTS(p)*sector_size;
+ if (SYS_IND(p) == 0)
+ continue;
if (!size)
continue;
if (is_extended_partition(p)) {
-
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] partitions/msdos.c
On Sat, Feb 26, 2005 at 02:28:45PM -0800, Linus Torvalds wrote: Would it not make more sense to just sanity-check the size itself, and throw it out if the partition size (plus start) is bigger than the disk size? I don't mind. There might well be people use use partition type 0, just because they just never _set_ the partition type.. I don't think Linux has ever cared about any type except for the extended partition type, so checking for zero doesn't seem very safe.. The default fdisk will assign type 83 to a newly created partition. One has to change it by hand to 0. So, I do not think testing against 0 is so bad. A heuristic, You give another heuristic. Probably there will be a point in time where we need both. (About type 0: DOS has used type 0 as definition of unused. It is not bad if Linux uses DOS-conventions for a DOS-type partition table.) Andries - 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] partitions/msdos.c
On Sat, Feb 26, 2005 at 03:12:28PM -0800, Linus Torvalds wrote: The default fdisk will assign type 83 to a newly created partition. Ok. Is that a it has done so for the last 5 years thing? The last twelve years. (About type 0: DOS has used type 0 as definition of unused. It is not bad if Linux uses DOS-conventions for a DOS-type partition table.) Agreed. At the same time, I could well imagine that some people might use such a type exactly to make DOS ignore it (but I assume the same is true of the regular 0x83 type too, so maybe I'm just being difficult). There's certainly a good argument for fixing a known problem (Uwe) and a small enough risk of it breaking anything else. Yes. Andries (Concerning the size version: it occurred to me that there is one very minor objection: For extended partitions so far the size did not normally play a role. Only the starting sector was significant. If, at some moment we decide also to check the size, then a weaker check, namely only checking for non-extended partitions, might be better at first.) (Yes, disk capacity is not always known - see e.g. ll_rw_blk.c: /* Test device or partition size, when known. */ See also sd.c, with the strange sdkp-capacity = 0x20; /* 1 GB - random */ In such cases we just access the blocks user space tells us to access.) - 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] partitions/msdos.c
On Sat, Feb 26, 2005 at 03:46:03PM -0800, Linus Torvalds wrote:
We should probably do the same for the
extended partition case, just to be consistent.
True.
diff -uprN -X /linux/dontdiff a/fs/partitions/msdos.c b/fs/partitions/msdos.c
--- a/fs/partitions/msdos.c 2004-12-29 03:39:55.0 +0100
+++ b/fs/partitions/msdos.c 2005-02-27 01:10:06.0 +0100
@@ -114,6 +114,9 @@ parse_extended(struct parsed_partitions
*/
for (i=0; i4; i++, p++) {
u32 offs, size, next;
+
+ if (SYS_IND(p) == 0)
+ continue;
if (!NR_SECTS(p) || is_extended_partition(p))
continue;
@@ -430,6 +433,8 @@ int msdos_partition(struct parsed_partit
for (slot = 1 ; slot = 4 ; slot++, p++) {
u32 start = START_SECT(p)*sector_size;
u32 size = NR_SECTS(p)*sector_size;
+ if (SYS_IND(p) == 0)
+ continue;
if (!size)
continue;
if (is_extended_partition(p)) {
-
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] partitions/msdos.c
On Sun, Feb 27, 2005 at 01:47:43AM +0100, Uwe Bonnes wrote: on a Suse 9.2 System with Suse Hotplug, the phantom partition was somehow recognized as Reiserfs, and then the Hotplug mechanism trying to mount the bogus partition as a Reiser Filesystem ended in an Oops... Always report the oops. It is well-known that mounting garbage may crash the kernel. Earlier the reply was don't do that then. Nowadays we have more layers of software trying to probe and do automatic things, and the kernel must survive attempts to mount garbage. Andries - 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] config option for default loglevel
On Sun, Feb 27, 2005 at 03:04:31AM +0100, Matthias Kunze wrote: +config DEFAULT_CONSOLE_LOGLEVEL You do not want to add yet another config option. Config options are used to select or deselect major subsystems, or support for specific hardware. Not to tweak variables. Adding more config variables is not an improvement. There are many ways to set the loglevel from user space. You add one on the command line - maybe useful in case more output is needed when the kernel crashes in early boot. I see no justification for DEFAULT_CONSOLE_LOGLEVEL. Andries - 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: Bogus REPORT_LUNS responses breaks SCSI LUN detection
On Sun, Feb 13, 2005 at 11:51:00PM -0500, Kurt Garloff wrote: > > SuSE 9.1 > > Vendor: easyRAID Model: X16 Rev: 0001 > > Type: Direct-Access ANSI SCSI revision: 03 > > scsi: host 0 channel 0 id 5 lun 0x6500737952414944 has a LUN larger than > > currently supported. > > Looks like random garbage. I read "e syRAID" > > Kernel 2.6, unknown distro > > Vendor: transtec Model: Rev: 0001 > > Type: Direct-Access ANSI SCSI revision: 03 > > On host 1 channel 0 id 1 only 128 (max_scsi_report_luns) of 536870896 > > luns reported, try increasing max_scsi_report_luns. > > scsi: host 1 channel 0 id 1 lun 0x7400616e73746563 has a LUN larger than > > currently supported. I read "t anstec" So - you might wish to investigate why the 2nd byte of "easyRAID" and of "transtec" was zeroed, and whether contents like this was to be expected (maybe the previous command was IDENTIFY?). Andries - 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: Bogus REPORT_LUNS responses breaks SCSI LUN detection
On Sun, Feb 13, 2005 at 11:51:00PM -0500, Kurt Garloff wrote: SuSE 9.1 Vendor: easyRAID Model: X16 Rev: 0001 Type: Direct-Access ANSI SCSI revision: 03 scsi: host 0 channel 0 id 5 lun 0x6500737952414944 has a LUN larger than currently supported. Looks like random garbage. I read e syRAID Kernel 2.6, unknown distro Vendor: transtec Model: Rev: 0001 Type: Direct-Access ANSI SCSI revision: 03 On host 1 channel 0 id 1 only 128 (max_scsi_report_luns) of 536870896 luns reported, try increasing max_scsi_report_luns. scsi: host 1 channel 0 id 1 lun 0x7400616e73746563 has a LUN larger than currently supported. I read t anstec So - you might wish to investigate why the 2nd byte of easyRAID and of transtec was zeroed, and whether contents like this was to be expected (maybe the previous command was IDENTIFY?). Andries - 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] keytables - the new keycode->keysym mapping
On Wed, Feb 16, 2005 at 07:20:35PM +0100, Jirka Bohac wrote:
> Now ... are there any more suggestions for any of the patches?
For the time being I look only at the diacr for unicode part.
The fragment below looks like a strange kludge.
> - if (diacr)
> - value = handle_diacr(vc, value);
> + if (diacr) {
> + v = handle_diacr(vc, value);
> +
> + if (kbd->kbdmode == VC_UNICODE) {
> + to_utf8(vc, v & 0x);
> + return;
> + }
> +
> + /*
> + * this makes at least latin-1 compose chars work
> + * even when using unicode keymap in non-unicode mode
> + */
> + value = v & 0xFF;
> + }
>
> if (dead_key_next) {
> dead_key_next = 0;
> @@ -637,7 +652,7 @@
> {
> if (up_flag)
> return;
> - diacr = (diacr ? handle_diacr(vc, value) : value);
> + diacr = (diacr ? handle_diacr(vc, value) & 0xff : value);
I see twice "& 0xff" but why?
I think this is broken.
Maybe the above "return" is broken as well. The original code
was good, so the only change should be to transport more than 8 bits.
Andries
-
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] keytables - the new keycode-keysym mapping
On Wed, Feb 16, 2005 at 07:20:35PM +0100, Jirka Bohac wrote:
Now ... are there any more suggestions for any of the patches?
For the time being I look only at the diacr for unicode part.
The fragment below looks like a strange kludge.
- if (diacr)
- value = handle_diacr(vc, value);
+ if (diacr) {
+ v = handle_diacr(vc, value);
+
+ if (kbd-kbdmode == VC_UNICODE) {
+ to_utf8(vc, v 0x);
+ return;
+ }
+
+ /*
+ * this makes at least latin-1 compose chars work
+ * even when using unicode keymap in non-unicode mode
+ */
+ value = v 0xFF;
+ }
if (dead_key_next) {
dead_key_next = 0;
@@ -637,7 +652,7 @@
{
if (up_flag)
return;
- diacr = (diacr ? handle_diacr(vc, value) : value);
+ diacr = (diacr ? handle_diacr(vc, value) 0xff : value);
I see twice 0xff but why?
I think this is broken.
Maybe the above return is broken as well. The original code
was good, so the only change should be to transport more than 8 bits.
Andries
-
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] keytables - the new keycode->keysym mapping
On Wed, Feb 09, 2005 at 06:19:21PM +0100, Jirka Bohac wrote:
> There are presently two ways around this, neither of them good enough
> 1) assigning one of the other modifier keysyms to the CapsLock key
>-- the LED will not work
True.
> But by adding two modifiers to almost every keyboard map, you would
> increase the space occupied by the keymaps four times. ... erm ... eight
> times, because there is also this "applkey" (application keypad) flag,
> that will be needed as another modifier.
But keymaps are allocated dynamically.
Any number of new modifiers does not cost anything until
one actually uses some particular modifier combination.
New modifiers are not expensive at all.
> - the proposed keyboard map file format is IMHO much much nicer
Keymap files live in user space. The layout of a keymap file
has no bearing on the kernel implementation of keymaps.
We want a map (keystroke,current_modifiers) -> keycode.
The present kernel code organizes things in maps, one for
each modifier combination that people want to use.
You want to organize things per keystroke.
I see no great advantages. Many small arrays allocated
by kmalloc() leads to more overhead - probably your version
would lead to larger memory usage, but I have not checked.
It looks like your code is larger.
It also looks like your code is slower, with a loop instead of
a table lookup.
(Not that those things are very important, but I do not see
significant advantages for your setup. Maybe you have numbers?)
Of more interest are the added features.
You come with a single big patch, but some parts are independent.
For example, I see
+struct kbdiacruc {
+ unsigned char diacr, base;
+ unsigned int result;/* UCS */
+};
Ten years ago we made the mistake of being too careful with memory.
Today it is a very bad idea to introduce new ioctls that act on
8-bit quantities. These must all be int's.
An ioctl somewhat in this style has been proposed several times,
and I have no serious objections. If you want it, separate it out
and make it a patch on its own.
Andries
-
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] keytables - the new keycode->keysym mapping
On Wed, Feb 09, 2005 at 05:55:00PM +0100, Vojtech Pavlik wrote: > On Wed, Feb 09, 2005 at 05:38:56PM +0100, Andries Brouwer wrote: >> On Wed, Feb 09, 2005 at 05:03:45PM +0100, Vojtech Pavlik wrote: >> >>>> It seems very unlikely that you cannot handle Czech with all >>>> combinations of 8 keys pressed, and need 9. >>> >>> A czech keyboard has the letters 'escrzyaie' with accents on the number >>> row of keys. With a Shift, they are supposed to produce the original >>> numbers, but with a CapsLock, they're supposed to produce the uppercase. >>> With a right alt or one of three czech dead keys they should produce >>> the [EMAIL PROTECTED]&*() symbols. >>> >>> It's kind of logical, kind of stupid, but anyway it's the national standard. >>> >>> You can't do that currently. The main problem is that CapsLock is >>> hardcoded to work as a Shift on keys and you can't make it work >>> differently for normal letter keys and for the upper row of keys. >> >> I think the fallacy in that reasoning is the idea that the key >> labeled CapsLock has to be bound to the kernel function named capslock. > > How do you make it control the CapsLock LED then? OK - I agree. The keyboard can do what you want, but there is no independent CapsLock LED control. Andries [not that I think the proposed change is a good idea, but now I understand why one would want to extend functionality] - 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] keytables - the new keycode->keysym mapping
On Wed, Feb 09, 2005 at 05:03:45PM +0100, Vojtech Pavlik wrote: > > It seems very unlikely that you cannot handle Czech with all > > combinations of 8 keys pressed, and need 9. > > A czech keyboard has the letters 'escrzyaie' with accents on the number > row of keys. With a Shift, they are supposed to produce the original > numbers, but with a CapsLock, they're supposed to produce the uppercase. > With a right alt or one of three czech dead keys they should produce > the [EMAIL PROTECTED]&*() symbols. > > It's kind of logical, kind of stupid, but anyway it's the national standard. > > You can't do that currently. The main problem is that CapsLock is > hardcoded to work as a Shift on keys and you can't make it work > differently for normal letter keys and for the upper row of keys. I think the fallacy in that reasoning is the idea that the key labeled CapsLock has to be bound to the kernel function named capslock. Andries - 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] keytables - the new keycode->keysym mapping
On Wed, Feb 09, 2005 at 02:26:54PM +0100, Jirka Bohac wrote: > Hi folks, > > find attached a patch that improves the keycode to keysym mapping in the > kernel. The current system has its limits, not allowing to implement keyboard > maps that people in different countries are used to. This patch tries to solve > this. Please, tell me what you think, and merge if possible. > > Current state: > -- > > The keycodes are mapped into keysyms using so-called keymaps. A keymap is > an array (of 255 elements per default) of keysyms, and there is one such > keymap for each modifier combination. There are 9 modifiers (such as Alt, > Ctrl, ), so one would need to allocate 2^9 = 512 such keymaps to make > use of all modifier combinations. However, there is a limit of 256 keymaps > to prevent them eating too much memory. In short, you need a whole keymap > to add a new modifier combination to a single key -- bad. > > The problem is, that not all keyboard modifiers can actually be assigned a > keyboard map - CapsLock and NumLock simply aren't on the list. The current keyboard code is far more powerful than you seem to think. Keymaps are allocated dynamically, and only few people use more than 16. You can have 256 keymaps, but they are not necessarily the 2^8 maps belonging to all 2^8 combinations of simultaneously pressed modifier keys. You can assign the "modifier" property to any key you like. You can assign the effect of each modifier key as you like. There are modifier keys with action while pressed, and modifier keys that act on the next non-modifier keystroke (say, for handicapped), and modifier keys that lock a state (say, to switch between Latin and Cyrillic keyboards). It seems very unlikely that you cannot handle Czech with all combinations of 8 keys pressed, and need 9. Please document carefully what you want to do and why you want to do it. I think most reasonable things are possible. (The weakest part is the support for Unicode / UTF8 - don't know whether improvement would be good - it is clear that one doesnt want to have full Unicode support in the kernel, but there is continued pressure to add some support for diacriticals. We might.) Andries - 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] keytables - the new keycode-keysym mapping
On Wed, Feb 09, 2005 at 02:26:54PM +0100, Jirka Bohac wrote: Hi folks, find attached a patch that improves the keycode to keysym mapping in the kernel. The current system has its limits, not allowing to implement keyboard maps that people in different countries are used to. This patch tries to solve this. Please, tell me what you think, and merge if possible. Current state: -- The keycodes are mapped into keysyms using so-called keymaps. A keymap is an array (of 255 elements per default) of keysyms, and there is one such keymap for each modifier combination. There are 9 modifiers (such as Alt, Ctrl, ), so one would need to allocate 2^9 = 512 such keymaps to make use of all modifier combinations. However, there is a limit of 256 keymaps to prevent them eating too much memory. In short, you need a whole keymap to add a new modifier combination to a single key -- bad. The problem is, that not all keyboard modifiers can actually be assigned a keyboard map - CapsLock and NumLock simply aren't on the list. The current keyboard code is far more powerful than you seem to think. Keymaps are allocated dynamically, and only few people use more than 16. You can have 256 keymaps, but they are not necessarily the 2^8 maps belonging to all 2^8 combinations of simultaneously pressed modifier keys. You can assign the modifier property to any key you like. You can assign the effect of each modifier key as you like. There are modifier keys with action while pressed, and modifier keys that act on the next non-modifier keystroke (say, for handicapped), and modifier keys that lock a state (say, to switch between Latin and Cyrillic keyboards). It seems very unlikely that you cannot handle Czech with all combinations of 8 keys pressed, and need 9. Please document carefully what you want to do and why you want to do it. I think most reasonable things are possible. (The weakest part is the support for Unicode / UTF8 - don't know whether improvement would be good - it is clear that one doesnt want to have full Unicode support in the kernel, but there is continued pressure to add some support for diacriticals. We might.) Andries - 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] keytables - the new keycode-keysym mapping
On Wed, Feb 09, 2005 at 05:03:45PM +0100, Vojtech Pavlik wrote: It seems very unlikely that you cannot handle Czech with all combinations of 8 keys pressed, and need 9. A czech keyboard has the letters 'escrzyaie' with accents on the number row of keys. With a Shift, they are supposed to produce the original numbers, but with a CapsLock, they're supposed to produce the uppercase. With a right alt or one of three czech dead keys they should produce the [EMAIL PROTECTED]*() symbols. It's kind of logical, kind of stupid, but anyway it's the national standard. You can't do that currently. The main problem is that CapsLock is hardcoded to work as a Shift on keys and you can't make it work differently for normal letter keys and for the upper row of keys. I think the fallacy in that reasoning is the idea that the key labeled CapsLock has to be bound to the kernel function named capslock. Andries - 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] keytables - the new keycode-keysym mapping
On Wed, Feb 09, 2005 at 05:55:00PM +0100, Vojtech Pavlik wrote: On Wed, Feb 09, 2005 at 05:38:56PM +0100, Andries Brouwer wrote: On Wed, Feb 09, 2005 at 05:03:45PM +0100, Vojtech Pavlik wrote: It seems very unlikely that you cannot handle Czech with all combinations of 8 keys pressed, and need 9. A czech keyboard has the letters 'escrzyaie' with accents on the number row of keys. With a Shift, they are supposed to produce the original numbers, but with a CapsLock, they're supposed to produce the uppercase. With a right alt or one of three czech dead keys they should produce the [EMAIL PROTECTED]*() symbols. It's kind of logical, kind of stupid, but anyway it's the national standard. You can't do that currently. The main problem is that CapsLock is hardcoded to work as a Shift on keys and you can't make it work differently for normal letter keys and for the upper row of keys. I think the fallacy in that reasoning is the idea that the key labeled CapsLock has to be bound to the kernel function named capslock. How do you make it control the CapsLock LED then? OK - I agree. The keyboard can do what you want, but there is no independent CapsLock LED control. Andries [not that I think the proposed change is a good idea, but now I understand why one would want to extend functionality] - 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] keytables - the new keycode-keysym mapping
On Wed, Feb 09, 2005 at 06:19:21PM +0100, Jirka Bohac wrote:
There are presently two ways around this, neither of them good enough
1) assigning one of the other modifier keysyms to the CapsLock key
-- the LED will not work
True.
But by adding two modifiers to almost every keyboard map, you would
increase the space occupied by the keymaps four times. ... erm ... eight
times, because there is also this applkey (application keypad) flag,
that will be needed as another modifier.
But keymaps are allocated dynamically.
Any number of new modifiers does not cost anything until
one actually uses some particular modifier combination.
New modifiers are not expensive at all.
- the proposed keyboard map file format is IMHO much much nicer
Keymap files live in user space. The layout of a keymap file
has no bearing on the kernel implementation of keymaps.
We want a map (keystroke,current_modifiers) - keycode.
The present kernel code organizes things in maps, one for
each modifier combination that people want to use.
You want to organize things per keystroke.
I see no great advantages. Many small arrays allocated
by kmalloc() leads to more overhead - probably your version
would lead to larger memory usage, but I have not checked.
It looks like your code is larger.
It also looks like your code is slower, with a loop instead of
a table lookup.
(Not that those things are very important, but I do not see
significant advantages for your setup. Maybe you have numbers?)
Of more interest are the added features.
You come with a single big patch, but some parts are independent.
For example, I see
+struct kbdiacruc {
+ unsigned char diacr, base;
+ unsigned int result;/* UCS */
+};
Ten years ago we made the mistake of being too careful with memory.
Today it is a very bad idea to introduce new ioctls that act on
8-bit quantities. These must all be int's.
An ioctl somewhat in this style has been proposed several times,
and I have no serious objections. If you want it, separate it out
and make it a patch on its own.
Andries
-
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: 2.6.10-ac12 + kernbench == oom-killer: (OSDL)
On Tue, Feb 08, 2005 at 02:57:07PM -0800, cliff white wrote: > Running 2.6.10-ac10 on the STP 1-CPU machines, we don't seem to be able to > complete > a kernbench run without hitting the OOM-killer. ( kernbench is multiple > kernel compiles, > of course ) Machine is 800 mhz PIII with 1GB memory. We reduce memory for > some of the runs. > > Typical results: > > Out of Memory: Killed process 14970 (cc1). > - > It looks like some oom-related stuff went into -ac10, will try retest with > -ac9 and -ac10, see what happens. Lemme know if we can do more I am always curious to hear how things are when you set /proc/sys/vm/overcommit_memory to 2 (and possibly /proc/sys/vm/overcommit_ratio to something appropriate). Andries - 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: 2.6.10-ac12 + kernbench == oom-killer: (OSDL)
On Tue, Feb 08, 2005 at 02:57:07PM -0800, cliff white wrote: Running 2.6.10-ac10 on the STP 1-CPU machines, we don't seem to be able to complete a kernbench run without hitting the OOM-killer. ( kernbench is multiple kernel compiles, of course ) Machine is 800 mhz PIII with 1GB memory. We reduce memory for some of the runs. Typical results: Out of Memory: Killed process 14970 (cc1). - It looks like some oom-related stuff went into -ac10, will try retest with -ac9 and -ac10, see what happens. Lemme know if we can do more I am always curious to hear how things are when you set /proc/sys/vm/overcommit_memory to 2 (and possibly /proc/sys/vm/overcommit_ratio to something appropriate). Andries - 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] Re: msdos/vfat defaults are annoying
On Mon, Feb 07, 2005 at 03:53:00PM +0900, Clemens Schwaighofer wrote: > >>Yeah, but the link order could be changed... Patch inlined. > > > > And just what does the link order (or changes thereof) have to do with that? > > because some distributions (eg gentoo) make a symlink to /proc/filesystems > > jupiter root # ls -l /etc/filesystems > lrwxrwxrwx 1 root root 19 Oct 25 11:18 /etc/filesystems -> > ../proc/filesystems > > and then its impossible to change the order. (unless you make a "hand > made" file of course). Ah, I had not met this particular form of brokenness before. If one does not specify a filesystem type to mount, mount will try its own collection of heuristics, looking for known magic numbers. This stuff comes in two versions, depending on whether mount was linked against the blkid library or not. When no magic is recognized, mount will try all filesystems listed in /proc/filesystems that were not rejected already because of wrong magic. The list in /proc/filesystems can be overridden by the file /etc/filesystems. That is useful for two reasons: (i) sometimes the kernel crashes when one tries to mount something with the wrong type, so /etc/filesystems can skip the types that must never be tried, and (ii) sometimes several types would succeed (e.g. msdos/vfat) and the user can override the kernel order. Making a symlink /etc/filesystems -> /proc/filesystems is meaningless. By the way, it is best to consider the kernel order as undefined. It plays a role when mounting the rootfs. If you get undesirable results at boot time, specify the rootfstype= boot option. It plays a role when generating /proc/filesystems. If you get undesirable results, adapt /etc/filesystems. It is not true that vfat is universally better than msdos. Some need one, some need the other. Instead of having a global order, one can have a per-mountpoint list in /etc/fstab. For example, /dev/foo/mntext2,msdos noauto 0 0 Finally, guessing is always bad. It is convenient in the short run but may lead to crashes and data loss in the long run. Andries - 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: Generating NLS modules
On Mon, Feb 07, 2005 at 09:10:38AM -0500, Pavel Fedin wrote: > Nobody answered so i repeat the question. > I think i found a way to make use of NLS table for HFS filesystem and > i'm going to try to implement it. But first i need to create NLS module > for codepage 10007 (Mac cyrillic). In the beginning of every existing > NLS module code i see comment which says that this file is automatically > generated from data found at unicode.org. Could you tell me where i can find a > convertor and what data it can use as input? I explored unicode.org and found > some conversion data at oss.software.ibm.com/icu/. The data is available in > UCM and XML formats. Are those files suitable? Last week or so I regenerated three NLS modules. Used a small thrice-only throwaway script. Don't know who generated the NLS modules first, or what software was used. - 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: Generating NLS modules
On Mon, Feb 07, 2005 at 09:10:38AM -0500, Pavel Fedin wrote: Nobody answered so i repeat the question. I think i found a way to make use of NLS table for HFS filesystem and i'm going to try to implement it. But first i need to create NLS module for codepage 10007 (Mac cyrillic). In the beginning of every existing NLS module code i see comment which says that this file is automatically generated from data found at unicode.org. Could you tell me where i can find a convertor and what data it can use as input? I explored unicode.org and found some conversion data at oss.software.ibm.com/icu/. The data is available in UCM and XML formats. Are those files suitable? Last week or so I regenerated three NLS modules. Used a small thrice-only throwaway script. Don't know who generated the NLS modules first, or what software was used. - 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] Re: msdos/vfat defaults are annoying
On Mon, Feb 07, 2005 at 03:53:00PM +0900, Clemens Schwaighofer wrote: Yeah, but the link order could be changed... Patch inlined. And just what does the link order (or changes thereof) have to do with that? because some distributions (eg gentoo) make a symlink to /proc/filesystems jupiter root # ls -l /etc/filesystems lrwxrwxrwx 1 root root 19 Oct 25 11:18 /etc/filesystems - ../proc/filesystems and then its impossible to change the order. (unless you make a hand made file of course). Ah, I had not met this particular form of brokenness before. If one does not specify a filesystem type to mount, mount will try its own collection of heuristics, looking for known magic numbers. This stuff comes in two versions, depending on whether mount was linked against the blkid library or not. When no magic is recognized, mount will try all filesystems listed in /proc/filesystems that were not rejected already because of wrong magic. The list in /proc/filesystems can be overridden by the file /etc/filesystems. That is useful for two reasons: (i) sometimes the kernel crashes when one tries to mount something with the wrong type, so /etc/filesystems can skip the types that must never be tried, and (ii) sometimes several types would succeed (e.g. msdos/vfat) and the user can override the kernel order. Making a symlink /etc/filesystems - /proc/filesystems is meaningless. By the way, it is best to consider the kernel order as undefined. It plays a role when mounting the rootfs. If you get undesirable results at boot time, specify the rootfstype= boot option. It plays a role when generating /proc/filesystems. If you get undesirable results, adapt /etc/filesystems. It is not true that vfat is universally better than msdos. Some need one, some need the other. Instead of having a global order, one can have a per-mountpoint list in /etc/fstab. For example, /dev/foo/mntext2,msdos noauto 0 0 Finally, guessing is always bad. It is convenient in the short run but may lead to crashes and data loss in the long run. Andries - 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: dm-crypt crypt_status reports key?
On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote: > (Actually it's a Multi Time Pad.) And you call this "crypto"? - 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: Joe User DOS kills Linux-2.6.10
On Thu, Feb 03, 2005 at 07:28:50AM -0500, linux-os wrote: > I ran badblocks (all night). There were none. It's a SCSI disk > and it requires chunks of DMA RAM for each write. The machine > just croaks when it gets low on RAM and tries to write to > SCSI swap which requires RAM. In some other post you said that you were writing past the end of the partition or disk. If the disk is fine and you have reproducible errors then the first thing to check is whether your partition table is correct, whether your swap signature is correct, whether the total size of the disk is recognized correctly at boot time. - 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: Joe User DOS kills Linux-2.6.10
On Thu, Feb 03, 2005 at 07:28:50AM -0500, linux-os wrote: I ran badblocks (all night). There were none. It's a SCSI disk and it requires chunks of DMA RAM for each write. The machine just croaks when it gets low on RAM and tries to write to SCSI swap which requires RAM. In some other post you said that you were writing past the end of the partition or disk. If the disk is fine and you have reproducible errors then the first thing to check is whether your partition table is correct, whether your swap signature is correct, whether the total size of the disk is recognized correctly at boot time. - 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: dm-crypt crypt_status reports key?
On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote: (Actually it's a Multi Time Pad.) And you call this crypto? - 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: Joe User DOS kills Linux-2.6.10
On Wed, Feb 02, 2005 at 01:23:43PM -0500, linux-os wrote:
>
> When I compile and run the following program:
>
> #include
> int main(int x, char **y)
> {
> pause();
> }
> ... as:
>
> ./xxx `yes`
>
> ... the following occurs after about 30 seconds (your mileage
> may vary):
>
> Additional sense: Peripheral device write fault
> end_request: I/O error, dev sdb, sector 34605780
> SCSI error : <0 0 1 0> return code = 0x802
> Info fld=0x2100101, Deferred sdb: sense key Medium Error
> Additional sense: Peripheral device write fault
> end_request: I/O error, dev sdb, sector 34603748
> SCSI error : <0 0 1 0> return code = 0x802
> Info fld=0x2100103, Deferred sdb: sense key Medium Error
When I run "sleep `yes`" under bash, all of swap space is filled,
and then bash says "realloc error ..." and exits.
No kernel problem, no bad bash problem.
If you do not run vm overcommit mode 2 then probably your bash
will be killed by the OOM killer, and if you are unlucky some
other stuff might be killed as well.
Concerning the SCSI errors, looks like you might have disk problems.
Bad blocks in your swap space. Recheck the disk.
Andries
-
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: Joe User DOS kills Linux-2.6.10
On Wed, Feb 02, 2005 at 01:23:43PM -0500, linux-os wrote:
When I compile and run the following program:
#include stdio.h
int main(int x, char **y)
{
pause();
}
... as:
./xxx `yes`
... the following occurs after about 30 seconds (your mileage
may vary):
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34605780
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x2100101, Deferred sdb: sense key Medium Error
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34603748
SCSI error : 0 0 1 0 return code = 0x802
Info fld=0x2100103, Deferred sdb: sense key Medium Error
When I run sleep `yes` under bash, all of swap space is filled,
and then bash says realloc error ... and exits.
No kernel problem, no bad bash problem.
If you do not run vm overcommit mode 2 then probably your bash
will be killed by the OOM killer, and if you are unlucky some
other stuff might be killed as well.
Concerning the SCSI errors, looks like you might have disk problems.
Bad blocks in your swap space. Recheck the disk.
Andries
-
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: Fw: [Bugme-new] [Bug 4137] New: nls_cp936.c is not synchronized with M$'s translation table
On Tue, Feb 01, 2005 at 01:14:39AM +0900, OGAWA Hirofumi wrote:
> Andries Brouwer <[EMAIL PROTECTED]> writes:
> > On Sun, Jan 30, 2005 at 09:25:33PM -0800, Andrew Morton wrote:
> >
> >> The nls_cp936.c is not synchronized with MS's translation table, there are
> >> some
> >> characters have different code from the code in updated table of MS.
> >> For example, the unicode for character 0xB8A3 (GBK) should be U+798F, but
> >> the
> >> code is U+FA1B in nls_cp936.c.
> >
> > OK - regenerated the tables.
>
> > @@ -1510,13 +1499,13 @@ static wchar_t c2u_FA[256] = {
> > - 0x2166,0x2167,0x2168,0x2169,0x,0xFFE4,0xFF07,0xFF02,/* 0x50-0x57 */
> > + 0x2166,0x2167,0x2168,0x2169,0xFFE2,0xFFE4,0xFF07,0xFF02,/* 0x50-0x57 */
>
> Microsoft is using this, and some other vendor is using 0x00AC. The
> both of those char code is valid for fatfs...
>
> Anyway, this patch looks good to me.
Let me cc the submitter of the bug report and linux-kernel.
Below a description of the changes in the four code pages 932, 936, 949, 950.
(They have been aligned to current Microsoft tables.)
Andries
nls_cp932.c:
0x -> 0xFFE2FULL WIDTH NOT SIGN
Was already present as 0x81CA and 0xEEF9.
Now also at 0xFA54.
nls_cp936.c:
0x2218 -> 0x00B0RING OPERATOR -> DEGREE SIGN
CJK Compatibility ideographs replaced by corresponding ordinary symbol.
0xF900 -> 0x8C48
0xF901 -> 0x66F4
0xF902 -> 0x8ECA
0xF903 -> 0x8CC8
0xF904 -> 0x6ED1
0xF905 -> 0x4E32
0xF906 -> 0x53E5
0xF908 -> 0x9F9C
0xF909 -> 0x5951
0xF90A -> 0x91D1
0xF90B -> 0x5587
0xF90C -> 0x5948
0xF90D -> 0x61F6
0xF90E -> 0x7669
0xF90F -> 0x7F85
0xF910 -> 0x863F
0xF911 -> 0x87BA
0xF912 -> 0x88F8
0xF913 -> 0x908F
0xF915 -> 0x6D1B
0xF916 -> 0x70D9
0xF917 -> 0x73DE
0xF918 -> 0x843D
0xF919 -> 0x916A
0xF91A -> 0x99F1
0xF91B -> 0x4E82
0xF91C -> 0x5375
0xF91D -> 0x6B04
0xF91E -> 0x721B
0xF91F -> 0x862D
0xF920 -> 0x9E1E
0xF921 -> 0x5D50
0xF922 -> 0x6FEB
0xF923 -> 0x85CD
0xF924 -> 0x8964
0xF925 -> 0x62C9
0xF926 -> 0x81D8
0xF927 -> 0x881F
0xF928 -> 0x5ECA
0xF929 -> 0x6717
0xF92A -> 0x6D6A
0xF92B -> 0x72FC
0xF92D -> 0x4F86
0xF92E -> 0x51B7
0xF92F -> 0x52DE
0xF930 -> 0x64C4
0xF931 -> 0x6AD3
0xF932 -> 0x7210
0xF933 -> 0x76E7
0xF934 -> 0x8001
0xF935 -> 0x8606
0xF936 -> 0x865C
0xF937 -> 0x8DEF
0xF938 -> 0x9732
0xF939 -> 0x9B6F
0xF93A -> 0x9DFA
0xF93B -> 0x788C
0xF93C -> 0x797F
0xF93D -> 0x7DA0
0xF93E -> 0x83C9
0xF93F -> 0x9304
0xF940 -> 0x9E7F
0xF941 -> 0x8AD6
0xF942 -> 0x58DF
0xF943 -> 0x5F04
0xF944 -> 0x7C60
0xF945 -> 0x807E
0xF946 -> 0x7262
0xF947 -> 0x78CA
0xF948 -> 0x8CC2
0xF949 -> 0x96F7
0xF94A -> 0x58D8
0xF94B -> 0x5C62
0xF94C -> 0x6A13
0xF94D -> 0x6DDA
0xF94E -> 0x6F0F
0xF94F -> 0x7D2F
0xF950 -> 0x7E37
0xF951 -> 0x964B
0xF952 -> 0x52D2
0xF953 -> 0x808B
0xF954 -> 0x51DC
0xF955 -> 0x51CC
0xF956 -> 0x7A1C
0xF957 -> 0x7DBE
0xF958 -> 0x83F1
0xF959 -> 0x9675
0xF95A -> 0x8B80
0xF95B -> 0x62CF
0xF95D -> 0x8AFE
0xF95E -> 0x4E39
0xF960 -> 0x6012
0xF962 -> 0x7570
0xF963 -> 0x5317
0xF964 -> 0x78FB
0xF965 -> 0x4FBF
0xF966 -> 0x5FA9
0xF967 -> 0x4E0D
0xF968 -> 0x6CCC
0xF969 -> 0x6578
0xF96A -> 0x7D22
0xF96B -> 0x53C3
0xF96C -> 0x585E
0xF96D -> 0x7701
0xF96E -> 0x8449
0xF970 -> 0x6BBA
0xF971 -> 0x8FB0
0xF972 -> 0x6C88
0xF973 -> 0x62FE
0xF974 -> 0x82E5
0xF975 -> 0x63A0
0xF976 -> 0x7565
0xF977 -> 0x4EAE
0xF978 -> 0x5169
0xF97A -> 0x6881
0xF97B -> 0x7CE7
0xF97C -> 0x826F
0xF97D -> 0x8AD2
0xF97E -> 0x91CF
0xF97F -> 0x52F5
0xF980 -> 0x5442
0xF981 -> 0x5973
0xF982 -> 0x5EEC
0xF983 -> 0x65C5
0xF984 -> 0x6FFE
0xF985 -> 0x792A
0xF986 -> 0x95AD
0xF987 -> 0x9A6A
0xF988 -> 0x9E97
0xF989 -> 0x9ECE
0xF98A -> 0x529B
0xF98B -> 0x66C6
0xF98C -> 0x6B77
0xF98D -> 0x8F62
0xF98E -> 0x5E74
0xF98F -> 0x6190
0xF990 -> 0x6200
0xF991 -> 0x649A
0xF992 -> 0x6F23
0xF993 -> 0x7149
0xF994 -> 0x7489
0xF996 -> 0x7DF4
0xF997 -> 0x806F
0xF998 -> 0x8F26
0xF999 -> 0x84EE
0xF99A -> 0x9023
0xF99B -> 0x934A
0xF99C -> 0x5217
0xF99D -> 0x52A3
0xF99E -> 0x54BD
0xF99F -> 0x70C8
0xF9A0 -> 0x88C2
0xF9A1 -> 0x8AAA
0xF9A2 -> 0x5EC9
0xF9A3 -> 0x5FF5
0xF9A4 -> 0x637B
0xF9A5 -> 0x6BAE
0xF9A6 -> 0x7C3E
0xF9A7 -> 0x7375
0xF9A8 -> 0x4EE4
0xF9A9 -> 0x56F9
0xF9AA -> 0x5BE7
0xF9AB -> 0x5DBA
0xF9AC -> 0x601C
0xF9AD -> 0x73B2
0xF9AE -> 0x7469
0xF9AF -> 0x7F9A
0xF9B0 -> 0x8046
0xF9B1 -> 0x9234
0xF9B2 -> 0x96F6
0xF9B3 -> 0x9748
0xF9B4 -> 0x9818
0xF9B5 -> 0x4F8B
0xF9B6 -> 0x79AE
0xF9B7 -> 0x91B4
0xF9B
