Re: [PATCH] documentation/svga.txt: update outdated file

ions are controlled by the kernel kconfig utility. > > Signed-off-by: Randy Dunlap <rdun...@infradead.org> Acked-By: Martin Mares <m...@ucw.cz> Martin

Re: [PATCH] documentation/svga.txt: update outdated file

kconfig utility. > > Signed-off-by: Randy Dunlap Acked-By: Martin Mares Martin

Re: [PATCH 19/29] svga.txt: standardize document format

> diff --git a/Documentation/svga.txt b/Documentation/svga.txt > index cd66ec836e4f..119f1515b1ac 100644 > --- a/Documentation/svga.txt > +++ b/Documentation/svga.txt > @@ -1,24 +1,31 @@ Acked-By: Martin Mares <m...@ucw.cz> Have a nice for

Re: [PATCH 19/29] svga.txt: standardize document format

> diff --git a/Documentation/svga.txt b/Documentation/svga.txt > index cd66ec836e4f..119f1515b1ac 100644 > --- a/Documentation/svga.txt > +++ b/Documentation/svga.txt > @@ -1,24 +1,31 @@ Acked-By: Martin Mares Have a nice fortnight -- Ma

Re: [PATCHv5 7/7] pciutils: Allow 32-bit domains

Hello! > PCI-e segments will continue to use the lower 16 bits as required by > ACPI. Special domains may use the full 32-bits. > > Signed-off-by: Keith Busch > --- > lib/filter.c |2 +- > lib/pci.h|2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCHv5 7/7] pciutils: Allow 32-bit domains

Hello! > PCI-e segments will continue to use the lower 16 bits as required by > ACPI. Special domains may use the full 32-bits. > > Signed-off-by: Keith Busch > --- > lib/filter.c |2 +- > lib/pci.h|2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) >

Re: [PATCH v2] pci: export class IDs from pci_ids.h

Hello! > That's a good idea. Martin, could you please answer the following: > assuming that linux exported linux/pci_ids.h providing class > IDs that are currently in /usr/include/pci/header.h > in a header /usr/include/linux/pci_ids.h, > would libpci be open to replacing part of >

Re: [PATCH v2] pci: export class IDs from pci_ids.h

Hello! That's a good idea. Martin, could you please answer the following: assuming that linux exported linux/pci_ids.h providing class IDs that are currently in /usr/include/pci/header.h in a header /usr/include/linux/pci_ids.h, would libpci be open to replacing part of

udev/hwdb support in pciutils (Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support)

Hi Tom! The support for hwdb has finally landed in mainline pciutils. I have modified your patch to bring it closer to the rest of device naming logic. Namely: • The interface to HWDB now lives in a separate source file lib/names-hwdb.c. It is called from the main entry point to

udev/hwdb support in pciutils (Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support)

Hi Tom! The support for hwdb has finally landed in mainline pciutils. I have modified your patch to bring it closer to the rest of device naming logic. Namely: • The interface to HWDB now lives in a separate source file lib/names-hwdb.c. It is called from the main entry point to

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

Hi! > Ping? Sorry for the delay, I was alternatingly ill and overloaded with other stuff... As I said before, I do not like the current implementation of hwdb much (it's too much tied to Linux, and hardware description strings, originally intended for internal use between the kernel and its

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

Hi! Ping? Sorry for the delay, I was alternatingly ill and overloaded with other stuff... As I said before, I do not like the current implementation of hwdb much (it's too much tied to Linux, and hardware description strings, originally intended for internal use between the kernel and its

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

Hello! > It does that per process doing that, and that's the problem for how > udev works/worked. The binary hwdb is on-disk and can be mmaped, and > there is no difference between initialization, first, or subsequent > queries. OK, point taken. I see that a mechanism for fast lookup of

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

Hello Kay, > Libpci and its linear search through megabytes of text files for evey > new query is too inefficient, that we cannot afford to use it during > early bootup. It was the largest hit left in bootup profiling on > machines booting userspace in the sub-1-second range on common > machines.

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

Hello Kay, Libpci and its linear search through megabytes of text files for evey new query is too inefficient, that we cannot afford to use it during early bootup. It was the largest hit left in bootup profiling on machines booting userspace in the sub-1-second range on common machines. It

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

Hello! It does that per process doing that, and that's the problem for how udev works/worked. The binary hwdb is on-disk and can be mmaped, and there is no difference between initialization, first, or subsequent queries. OK, point taken. I see that a mechanism for fast lookup of hardware

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

Hello and sorry for the delay, > >> + if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ] > >> ; then > >> + HWDB=yes > >> + else > >> + HWDB=no > >> + fi > > > > Does this make sense? Does every version of libudev support hwdb? > > Good

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

Hello and sorry for the delay, + if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ] ; then + HWDB=yes + else + HWDB=no + fi Does this make sense? Does every version of libudev support hwdb? Good point. I'll replace it with a

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

Hello! First of all: Sorry for not replying to the first mail. I do not follow linux-pci too much these days (or, I do that in big batches). > This lets you select hwdb support at compile time. > > hwdb is an efficient hardware database shipped with recent versions of udev. > It contains among

Re: [PATCH RESEND][pciutils] libpci: pci_id_lookup - add udev/hwdb support

Hello! First of all: Sorry for not replying to the first mail. I do not follow linux-pci too much these days (or, I do that in big batches). This lets you select hwdb support at compile time. hwdb is an efficient hardware database shipped with recent versions of udev. It contains among

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

> Reading past the first 256 bytes of the sysfs file should be enough > -- only root can do that (other users get only 64 bytes anyway) and > problems with reading random registers have hopefully taught programs > not to read blindly a long time ago. ... except for lspci itself which reads the

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

Hello! > (and yes I realize this needs lspci to be expanded some to set the > flag if the admin really asks for it, but such is life) Reading past the first 256 bytes of the sysfs file should be enough -- only root can do that (other users get only 64 bytes anyway) and problems with reading

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

Hello! (and yes I realize this needs lspci to be expanded some to set the flag if the admin really asks for it, but such is life) Reading past the first 256 bytes of the sysfs file should be enough -- only root can do that (other users get only 64 bytes anyway) and problems with reading random

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

Reading past the first 256 bytes of the sysfs file should be enough -- only root can do that (other users get only 64 bytes anyway) and problems with reading random registers have hopefully taught programs not to read blindly a long time ago. ... except for lspci itself which reads the first

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

Hello! > - During that probe, you set a flag if any device has capabilities that > extend beyond 0xff. Can this work? The extended capabilities are not linked to the normal ones in any way. Have a nice fortnight -- Martin `MJ' Mares

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

Hi! > The fact is, 99% of the hardware you buy *today* has absolutely zero need > for extended PCI config access. In fact, I would not be surprised at all > if most hardware sold today generally doesn't have *any* devices that even > have config registers in the 0x100+ range. Most PCI Express

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

Hi! The fact is, 99% of the hardware you buy *today* has absolutely zero need for extended PCI config access. In fact, I would not be surprised at all if most hardware sold today generally doesn't have *any* devices that even have config registers in the 0x100+ range. Most PCI Express

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

Hello! - During that probe, you set a flag if any device has capabilities that extend beyond 0xff. Can this work? The extended capabilities are not linked to the normal ones in any way. Have a nice fortnight -- Martin `MJ' Mares

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

Hello! > it's not "just a couple of chipsets", it's actually > * a whole lot of bioses > * at least one whole CPU generation > * .. > * .. > > Do you really want to code all of that into your userspace access code as > well? No, I certainly don't. But I expect this to be handled reasonably in

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

Hello! > Just make it so. The name is fine, the concept is unavoidable. The people > who complain are whiners that haven't ever had to deal with the fact that > there are broken machines around. I complain as well as the maintainer of the pciutils. Breaking all userspace accesses to extended

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

Hello! Just make it so. The name is fine, the concept is unavoidable. The people who complain are whiners that haven't ever had to deal with the fact that there are broken machines around. I complain as well as the maintainer of the pciutils. Breaking all userspace accesses to extended

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

Hello! it's not just a couple of chipsets, it's actually * a whole lot of bioses * at least one whole CPU generation * .. * .. Do you really want to code all of that into your userspace access code as well? No, I certainly don't. But I expect this to be handled reasonably in the

Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch

Hello! > > Maybe we should do all bus scanning with conf1 and then try if > > MMCONFIG returns the same values? > > that is already in the code today but not nearly enough; there's a ton > of cases where it's "touch mmconfig and the box is dead"... Argh. However I still do not think it is an

Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch

Hello! Maybe we should do all bus scanning with conf1 and then try if MMCONFIG returns the same values? that is already in the code today but not nearly enough; there's a ton of cases where it's touch mmconfig and the box is dead... Argh. However I still do not think it is an acceptable

Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch

Hello! > something like > int pci_enable_mmconfig(struct pci_dev *pdev) ? > sounds like a very solid plan to me... Please remember that the driver is not the sole user of the PCI config space -- user-space programs (e.g., lspci) can access it via sysfs, too. Should we force users of such

Re: pci-disable-decode-of-io-memory-during-bar-sizing.patch

Hello! something like int pci_enable_mmconfig(struct pci_dev *pdev) ? sounds like a very solid plan to me... Please remember that the driver is not the sole user of the PCI config space -- user-space programs (e.g., lspci) can access it via sysfs, too. Should we force users of such programs

Re: Why are ipmi modules being loaded?

Hello! > Hmm, is lspci truncating the class code? > > > 01:00.4 Serial bus controller [0c07]: Intel Corporation 82573E KCS (Active > Management) [8086:108e] (rev 03) > > Because this smells like an IPMI-ish device. Yes, it is a IPMI class code, only older versions of lspci know nothing about

Re: Why are ipmi modules being loaded?

Hello! Hmm, is lspci truncating the class code? 01:00.4 Serial bus controller [0c07]: Intel Corporation 82573E KCS (Active Management) [8086:108e] (rev 03) Because this smells like an IPMI-ish device. Yes, it is a IPMI class code, only older versions of lspci know nothing about it, so

Re: Understanding lspci output

Hello! > I ran lspci -vvv on a system: > http://linux.kernel.free.fr/halt/lspci.txt > > (I used lspci version 2.2.5 in case it matters.) > > But I'm having a hard time making sense of the output. > > 1. How many PCI buses are there in the system? Two, just see the bus numbers of the devices.

Re: Understanding lspci output

Hello! I ran lspci -vvv on a system: http://linux.kernel.free.fr/halt/lspci.txt (I used lspci version 2.2.5 in case it matters.) But I'm having a hard time making sense of the output. 1. How many PCI buses are there in the system? Two, just see the bus numbers of the devices.

Re: [patch 5/5] x86: Set PCI config space size to extended for AMD Barcelona

Hi! > it's so very unfortunate the PCI standard has no feature bit to indicate > the presence of ECS. > > FWIW in my testing on a range of machines spanning 7 or 8 years i could > read config space reg 256... and get 0x when the device didn't > support ECS, and get valid data when the

Re: [patch 5/5] x86: Set PCI config space size to extended for AMD Barcelona

Hi! it's so very unfortunate the PCI standard has no feature bit to indicate the presence of ECS. FWIW in my testing on a range of machines spanning 7 or 8 years i could read config space reg 256... and get 0x when the device didn't support ECS, and get valid data when the

Re: [PATCH] [467/2many] MAINTAINERS - SVGA HANDLING

> Martin, do you still want to be CC'd on changes > to arch/i386/boot/vid* here? Yes, I would like to. Although HPA has rewritten the code to C, the logic remains. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]>

Re: [PATCH] [467/2many] MAINTAINERS - SVGA HANDLING

Martin, do you still want to be CC'd on changes to arch/i386/boot/vid* here? Yes, I would like to. Although HPA has rewritten the code to C, the logic remains. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED]

Re: [PATCH] [467/2many] MAINTAINERS - SVGA HANDLING

> SVGA HANDLING > P:Martin Mares > M:[EMAIL PROTECTED] > L:[EMAIL PROTECTED] > S:Maintained > F:Documentation/svga.txt > F:arch/i386/boot/video.S Please also kill linux-video and replace it by linux-kernel. Not a single on-topic mail has arrived to li

Re: [PATCH] [467/2many] MAINTAINERS - SVGA HANDLING

Hello! > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index e0020d6..cde4be1 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4440,6 +4440,9 @@ P: Martin Mar

Re: [PATCH] [467/2many] MAINTAINERS - SVGA HANDLING

Hello! Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index e0020d6..cde4be1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4440,6 +4440,9 @@ P: Martin Mares M: [EMAIL PROTECTED] L: [EMAIL PROTECTED

Re: [PATCH] [467/2many] MAINTAINERS - SVGA HANDLING

SVGA HANDLING P:Martin Mares M:[EMAIL PROTECTED] L:[EMAIL PROTECTED] S:Maintained F:Documentation/svga.txt F:arch/i386/boot/video.S Please also kill linux-video and replace it by linux-kernel. Not a single on-topic mail has arrived to linux-video in a couple

Re: [x86 setup 27/33] Video mode probing support for the new x86 setup code

in > current versions of those chips -- frequently, support for those modes > have been dropped from recent video BIOSes due to space constraints, > but the video BIOS signatures are still the same. Acked-By: Martin Mares <[EMAIL PROTECTED]> Have a ni

Re: [x86 setup 27/33] Video mode probing support for the new x86 setup code

versions of those chips -- frequently, support for those modes have been dropped from recent video BIOSes due to space constraints, but the video BIOS signatures are still the same. Acked-By: Martin Mares [EMAIL PROTECTED] Have a nice fortnight -- Martin `MJ' Mares

Re: x86 setup rewrite tree ready for flamage^W review

Hello! > As far as I could tell, "scan" simply caused the nonstandard video > driver scan modules (unsafe probes) to be invoked. Since those modules > are no longer present, there appeared to be no need for them. The VGA > and VESA probes are safe. "scan" is still useful, because it is able to

Re: x86 setup rewrite tree ready for flamage^W review

Hello! As far as I could tell, scan simply caused the nonstandard video driver scan modules (unsafe probes) to be invoked. Since those modules are no longer present, there appeared to be no need for them. The VGA and VESA probes are safe. scan is still useful, because it is able to find

Re: arch/i386/boot rewrite, and all the hard-coded video cards

Hi! > I mean the SVGA chip-specific code. Feel free to kill it, anybody using these cards is very unlikely to run a 2.6.x kernel. However, the BIOS mode switching is still useful. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL

Re: arch/i386/boot rewrite, and all the hard-coded video cards

Hi! I mean the SVGA chip-specific code. Feel free to kill it, anybody using these cards is very unlikely to run a 2.6.x kernel. However, the BIOS mode switching is still useful. Have a nice fortnight -- Martin `MJ' Mares [EMAIL

Re: [PATCH] vt: Do not clear UTF when resetting console

Hello! > Please note that I have dropped this patch in favor of this one: > > http://lkml.org/lkml/2007/4/2/422 Yes, this sounds very reasonable. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/

Re: [PATCH] vt: Do not clear UTF when resetting console

Hello! Please note that I have dropped this patch in favor of this one: http://lkml.org/lkml/2007/4/2/422 Yes, this sounds very reasonable. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of

Re: [PATCH] vt: Do not clear UTF when resetting console

Hello! > Does whatever defines what these escapes mean, have any comment to make > about UTF-8? If not, why can't we declare that UTF-8 mode is the "reset" > mode, the default that would be dropped to on a full reset, and if > anyone wanted to switch that out to non-default not-UTF-8 mode, they >

Re: [PATCH] vt: Do not clear UTF when resetting console

Hello! > Resetting the console, either by ANSI escape sequences or by the reset > utility, > will drop the console back to legacy (non-UTF-8) mode. Yes, and as far as I understand the logic behind these escape sequences, it's the intended behavior, not a bug. The escape sequence for terminal

Re: [PATCH] vt: Do not clear UTF when resetting console

Hello! Resetting the console, either by ANSI escape sequences or by the reset utility, will drop the console back to legacy (non-UTF-8) mode. Yes, and as far as I understand the logic behind these escape sequences, it's the intended behavior, not a bug. The escape sequence for terminal

Re: [PATCH] vt: Do not clear UTF when resetting console

Hello! Does whatever defines what these escapes mean, have any comment to make about UTF-8? If not, why can't we declare that UTF-8 mode is the reset mode, the default that would be dropped to on a full reset, and if anyone wanted to switch that out to non-default not-UTF-8 mode, they could,

Re: GPL vs non-GPL device drivers

Hello! > Assuming these need not be GPL, I have a problem with > EXPORT_SYMBOL_GPL and the general trend in the direction of making > proprietary drivers harder on companies. Most kernel developers did always say they don't agree with proprietary drivers, don't want to support them and that they

Re: GPL vs non-GPL device drivers

Hello! Assuming these need not be GPL, I have a problem with EXPORT_SYMBOL_GPL and the general trend in the direction of making proprietary drivers harder on companies. Most kernel developers did always say they don't agree with proprietary drivers, don't want to support them and that they

Re: GPL vs non-GPL device drivers

Hello! > >I think you have a bit of a misunderstanding... Linux is not royalty > >free. Just the royalty is not in the form of cash, but in the form of > >having to give your improvements back to the open source world. > > Sure. But this is not legally binding. Maybe it's not, but it certainly

Re: GPL vs non-GPL device drivers

Hello! I think you have a bit of a misunderstanding... Linux is not royalty free. Just the royalty is not in the form of cash, but in the form of having to give your improvements back to the open source world. Sure. But this is not legally binding. Maybe it's not, but it certainly doesn't

Re: somebody dropped a (warning) bomb

Hello! > void* comparisons are unsigned. Period. As far as the C standard is concerned, there is no relationship between comparison on pointers and comparison of their values casted to uintptr_t. The address space needn't be linear and on some machines it isn't. So speaking about signedness of

Re: somebody dropped a (warning) bomb

Hello! void* comparisons are unsigned. Period. As far as the C standard is concerned, there is no relationship between comparison on pointers and comparison of their values casted to uintptr_t. The address space needn't be linear and on some machines it isn't. So speaking about signedness of

Re: [RFC] pci_bus conversion to struct device

Hello! > So, if it were to stay, where in the tree should it be? Hanging off of > the pci device that is the bridge? Or just placing these files within > the pci device directory itself, as it is the bridge. I originally didn't realize that we already represent devices on the subordinate bus

Re: [RFC] pci_bus conversion to struct device

Hello! > I recommend we just delete the pci_bus class. I don't think it serves > any useful purpose. The bridge can be inferred frmo the sysfs hierarchy > (not to mention lspci will tell you). The cpuaffinity file should be > moved from the bus to the device -- it really doesn't make any sense

Re: [RFC] pci_bus conversion to struct device

Hello! I recommend we just delete the pci_bus class. I don't think it serves any useful purpose. The bridge can be inferred frmo the sysfs hierarchy (not to mention lspci will tell you). The cpuaffinity file should be moved from the bus to the device -- it really doesn't make any sense to

Re: [RFC] pci_bus conversion to struct device

Hello! So, if it were to stay, where in the tree should it be? Hanging off of the pci device that is the bridge? Or just placing these files within the pci device directory itself, as it is the bridge. I originally didn't realize that we already represent devices on the subordinate bus as

Re: O_DIRECT question

Hello! > Maybe you need to say why you want to use O_DIRECT with its terrible > performance? Incidentally, I was writing an external-memory radix-sort some time ago and it turned out that writing to 256 files at once is much faster with O_DIRECT than through the page cache, very likely because

Re: O_DIRECT question

Hello! Maybe you need to say why you want to use O_DIRECT with its terrible performance? Incidentally, I was writing an external-memory radix-sort some time ago and it turned out that writing to 256 files at once is much faster with O_DIRECT than through the page cache, very likely because the

Re: Finding hardlinks

Hello! > You mean POSIX compliance is impossible? So what? It is possible to > implement an approximation that is _at least_ as good as samefile(). > One really dumb way is to set st_ino to the 'struct inode' pointer for > example. That will sure as hell fit into 64bits and will give a >

Re: Finding hardlinks

Hello! You mean POSIX compliance is impossible? So what? It is possible to implement an approximation that is _at least_ as good as samefile(). One really dumb way is to set st_ino to the 'struct inode' pointer for example. That will sure as hell fit into 64bits and will give a unique

Re: Finding hardlinks

Hello! > High probability is all you have. Cosmic radiation hitting your > computer will more likly cause problems, than colliding 64bit inode > numbers ;) No. If you assign 64-bit inode numbers randomly, 2^32 of them are sufficient to generate a collision with probability around 50%.

Re: Finding hardlinks

Hello! High probability is all you have. Cosmic radiation hitting your computer will more likly cause problems, than colliding 64bit inode numbers ;) No. If you assign 64-bit inode numbers randomly, 2^32 of them are sufficient to generate a collision with probability around 50%.

Re: Binary Drivers

Hello! > I disagree. The manufacturer has a right to choose to sell its devices > under any legal business model. Part of that model is deciding what > level of support to provide and what systems to support in selling it. At the very least, if they decide that they wish to provide a binary-only

Re: Binary Drivers

Hello! I disagree. The manufacturer has a right to choose to sell its devices under any legal business model. Part of that model is deciding what level of support to provide and what systems to support in selling it. At the very least, if they decide that they wish to provide a binary-only

Re: Entropy Pool Contents

Hello! > That is exactly my point. Since you can not tell how much randomness is > in the data you provide, you can not tell the kernel how much to add to > its entropy estimate. Instead it just has to estimate based on the > amount of data you provide. No, the only safe thing the kernel

Re: Entropy Pool Contents

Hello! > I still don't see how feeding tons of zeros ( or some other carefully > crafted sequence ) in will not decrease the entropy of the pool ( even > if it does so in a way that is impossible to predict ), but assuming it > can't, what good does a non root user do by writing to random?

Re: Entropy Pool Contents

Hello! > You aren't dumping and restoring the entropy pool; you are dumping > random data generated by the pool, and using that data to stir the new > entropy pool after the next boot. There is no direct relationship > between the entropy of the old and new pools. The kernel needs to >

Re: Entropy Pool Contents

Hello! > After a reboot the entropy estimate starts at zero, so if you are adding > data to the pool from the previous boot, you DO want the estimate to > increase because you are, in fact, adding entropy. I'm adding entropy, but unless I record the exact amount of entropy when dumping the

Re: Entropy Pool Contents

Hello! > - Whether you automatically bump up the entropy estimate when > root users write to /dev/random is a design choice where you could > reasonably go either way. On the one hand, you might want to ensure > that root has to take some explicit action to allege that it is >

Re: Entropy Pool Contents

Hello! - Whether you automatically bump up the entropy estimate when root users write to /dev/random is a design choice where you could reasonably go either way. On the one hand, you might want to ensure that root has to take some explicit action to allege that it is

Re: Entropy Pool Contents

Hello! After a reboot the entropy estimate starts at zero, so if you are adding data to the pool from the previous boot, you DO want the estimate to increase because you are, in fact, adding entropy. I'm adding entropy, but unless I record the exact amount of entropy when dumping the pool,

Re: Entropy Pool Contents

Hello! You aren't dumping and restoring the entropy pool; you are dumping random data generated by the pool, and using that data to stir the new entropy pool after the next boot. There is no direct relationship between the entropy of the old and new pools. The kernel needs to decide

Re: Entropy Pool Contents

Hello! I still don't see how feeding tons of zeros ( or some other carefully crafted sequence ) in will not decrease the entropy of the pool ( even if it does so in a way that is impossible to predict ), but assuming it can't, what good does a non root user do by writing to random? Even

Re: Entropy Pool Contents

Hello! That is exactly my point. Since you can not tell how much randomness is in the data you provide, you can not tell the kernel how much to add to its entropy estimate. Instead it just has to estimate based on the amount of data you provide. No, the only safe thing the kernel can do

Re: multiple independent keyboard kernel support

Hello! > Btw, Aivils Stoss created a nice way to make several X instances have > separate keyboards - see the linux-console archives for the faketty > driver. I haven't looked recently, but when I tried that several years ago, the biggest problem was to make two simultaneously running X servers

Re: multiple independent keyboard kernel support

Hello! Btw, Aivils Stoss created a nice way to make several X instances have separate keyboards - see the linux-console archives for the faketty driver. I haven't looked recently, but when I tried that several years ago, the biggest problem was to make two simultaneously running X servers not

Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Hello! > We trust hardware, anyway. Like your disk *could* accidentaly turn on > setuid bit on /bin/bash, and we do not insist on userspace > disk-validator. But there is a very important difference: the most likely (both in theory and practice) failure of a disk is clearly visible, while

Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Hello! We trust hardware, anyway. Like your disk *could* accidentaly turn on setuid bit on /bin/bash, and we do not insist on userspace disk-validator. But there is a very important difference: the most likely (both in theory and practice) failure of a disk is clearly visible, while failures

Re: [patch 3/2] drivers/char/vt.c: remove unnecessary code

Hello! > I agree :) . But, if we look to the code, we can notice that there is actually > no reason for npar to be unsigned. What do you think of this version? What does it try to solve? Your version is in no way better than the previous one. The previous one was more readable and it's quite

Re: [patch 3/2] drivers/char/vt.c: remove unnecessary code

Hello! I agree :) . But, if we look to the code, we can notice that there is actually no reason for npar to be unsigned. What do you think of this version? What does it try to solve? Your version is in no way better than the previous one. The previous one was more readable and it's quite

Re: [PATCH 1/1] PCI: Dynids - passing driver data

Hello! > >Which is a good thing, right? "driver_data" is usually a pointer to > >somewhere. Having userspace specify it would not be a good thing. > > That depends on the driver usage, and the patch allows it to be > configurable and defaults to not being used. Maybe we could just define the

Re: [PATCH 1/1] PCI: Dynids - passing driver data

Hello! Which is a good thing, right? driver_data is usually a pointer to somewhere. Having userspace specify it would not be a good thing. That depends on the driver usage, and the patch allows it to be configurable and defaults to not being used. Maybe we could just define the

Re: lspci != scanpci !?

Hello! > Now the scanpci command shows the M7101 BUT lspci and /proc/pci, > /proc/bus/pci, /sys/bus/pci NOT. What can I do? Is there anything like a > "update_pci" command? What does `lspci -vv -M' and `lspci -vv -M -H1' print? (Please Cc to me, I usually read LKML in large batches.)

Re: lspci != scanpci !?

Hello! Now the scanpci command shows the M7101 BUT lspci and /proc/pci, /proc/bus/pci, /sys/bus/pci NOT. What can I do? Is there anything like a update_pci command? What does `lspci -vv -M' and `lspci -vv -M -H1' print? (Please Cc to me, I usually read LKML in large batches.)

Re: PATCH 2.4.4.3: pci_enable/disable_device stuff

Hi! > The attached patch does two things: > > 1) Take PCI devices to D0 state before enabling them. We both think > this is the right thing to do, but there is always the crazy chance this > change will break something. So, think twice before applying, but IMHO > apply :) I'm not able to

Re: PATCH 2.4.4.3: pci_enable/disable_device stuff

Hi! The attached patch does two things: 1) Take PCI devices to D0 state before enabling them. We both think this is the right thing to do, but there is always the crazy chance this change will break something. So, think twice before applying, but IMHO apply :) I'm not able to cite the

  1   2   >