[PATCH] pci: print out DMA mask info

On Fri, Oct 10, 2008 at 09:46:33AM -0700, Yinghai Lu wrote:[color=blue]
> Matthew Wilcox wrote:[color=green]
> >
> > By the way, commit 8f286c33f1e838d631f4a3260b33efce4bc5973c is a really
> > bad idea. It is very helpful to see which bitmasks are used by real
> > devices, and which ones aren't. It should be reverted, IMO.[/color]
>
> why? did you point to wrong commit?[/color]

No, that's the commit I meant.
[color=blue]
> commit 8f286c33f1e838d631f4a3260b33efce4bc5973c
> Author: Andrew Morton <akpm@linux-foundation.org>
> Date: Thu Oct 18 03:05:07 2007 -0700
>
> -#define DMA_BIT_MASK(n) ((1ULL<<(n))-1)
> +#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
>
> -#define DMA_64BIT_MASK (~0ULL)
> +/*
> + * NOTE: do not use the below macros in new code and do not add new definitions
> + * here.
> + *
> + * Instead, just open-code DMA_BIT_MASK(n) within your driver[/color]

Open-coding DMA_BIT_MASK() within your driver means that we no longer
have a canonical list of DMA masks in one place. Instead we have to
grep the entire tree and come up with more-or-less complex scripts to
figure out which bit masks are actually in use.

--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

> Open-coding DMA_BIT_MASK() within your driver means that we no longer[color=blue]
> have a canonical list of DMA masks in one place. Instead we have to
> grep the entire tree and come up with more-or-less complex scripts to
> figure out which bit masks are actually in use.[/color]

Out of curiousity, why do we care about that list?

- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Fri, Oct 10, 2008 at 11:40:56AM +0900, FUJITA Tomonori wrote:[color=blue]
> IIRC, except for one SGI architecture, coherent_dma_mask is
> meaningless, dma_mask is always equal to coherent_dma_mask.[/color]

Not correct. Several PCI-X devices can only do 32-bit DMA to control
data but can do 64-bit DMA for payload data. I don't have the list off
the top of my head but that is the origin of coherent DMA mask.
[color=blue]
> Lots of
> IOMMU implementations ignore coherent_dma_mask and use dma_mask for
> alloc_coherent().[/color]

That sounds like a bug. And I don't think it's "lots".
[color=blue]
> Some drivers don't set up coherent_dma_mask.[/color]

They probably should. Current default is 32-bits for PCI devices.
[color=blue]
> Theoretically, we need to fix this but it doesn't cause any
> problem. That's why nobody cares about it, I guess.[/color]

Agreed - for the "supported" configurations, it works.

hth,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Fri, Oct 10, 2008 at 04:32:07PM +0900, FUJITA Tomonori wrote:
....[color=blue][color=green][color=darkred]
> > > Well, that's because I wrote gart's alloc_coherent and introduced
> > > dma_alloc_coherent_mask. ;)[/color]
> >
> > oh. it is in tip[/color]
>
> Yeah, it's in tip. But the current gart code uses coherent_dma_mask
> properly (GART in tip works in the same way as the current
> GART). IIRC, other X86 hardware IOMMUs (VT-d, Calgary, AMD) uses
> dma_mask in dma_alloc_coherent (AMD in tip uses coherent_dma_mask).[/color]

This is a bug. Care to submit a patch to fix it?
I don't have any of the docs or HW (VT-d, Calgary) to test it.

[color=blue][color=green]
> > then can we remove consistent_dma_mask? just use dma_mask instead for all.[/color]
>
> I don't think we can. One architecture needs it. The above usb
> chip seems to need it.[/color]

As noted before, several PCI-X devices support 64-bit DMA for payload
data but only 32-bit DMA for control data.

thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Thu, Oct 09, 2008 at 04:05:57PM -0700, Yinghai Lu wrote:[color=blue]
> Grant Grundler wrote:[color=green]
> > On Thu, Oct 09, 2008 at 02:51:32PM -0700, Yinghai Lu wrote:[color=darkred]
> >> On Thu, Oct 9, 2008 at 2:35 PM, Matthew Wilcox <matthew@wil.cx> wrote:
> >>> Why's that interesting to the sysadmin of the machine? To the driver
> >>> writer, certainly. But what's the use of it to the people using the
> >>> machine?[/color]
> > ...[color=darkred]
> >> make linux kernel act like black box as other os?[/color]
> >
> > I don't understand your reply.
> > If someone thinks linux is a black box, printing this message won't help them.
> >[/color]
> could find out easily why some driver doesn't set dma mask correctly.
> like why
> qlogic qla2xxx only set consistent to 64bit,
> emulex lpfc not set consistent to 64bit[/color]

I agree making the information available is a good idea. It's just
not going to help anyone 99% of the time and isn't a requirement for
booting the machine.
[color=blue][color=green]
> >
> > "To flag use of bounce buffer or other suboptimal behaviors" could be debated.
> >
> >
> > Regarding associating the output with other PCI messages, I'd hope the fact
> > that the /sys entry is in the same directory as other sys files would be
> > enough clue to associate those together. e.g.:
> > grundler <2068>cd /sys/bus/pci/devices/0000\:01\:00.0/
> > grundler <2069>ls
> > broken_parity_status driver@ irq resource0 subsystem_device
> > bus@ enable local_cpus resource1 subsystem_vendor
> > class i2c-0/ modalias resource3 uevent
> > config i2c-1/ power/ rom vendor
> > device i2c-2/ resource subsystem@
> >[/color]
>
> add dma_mask coherent_dma_mask here?[/color]

Yes, if there is no other more obvious place.
It's just a suggestion which I happen to think is better than
adding more boot time messages.

thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Fri, Oct 10, 2008 at 08:48:08AM -0700, Jesse Barnes wrote:
....[color=blue]
> Another option would be to add a 'warn_dma_mask=0xxxxxxxxx' boot option that
> would trigger in the actual DMA mask setting routines. It would let you
> choose the mask you'd like to see warnings about. Yinghai?[/color]

No, please don't. We have too many command line options already.

Dumping dma_mask and dma_consistent_mask from /sys is not hard.
I'd prefer Yinghai get credit for doing this since he's raised the issue
and took the time to submit a patch.

thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Fri, Oct 10, 2008 at 10:18:33AM -0700, Roland Dreier wrote:[color=blue][color=green]
> > Open-coding DMA_BIT_MASK() within your driver means that we no longer
> > have a canonical list of DMA masks in one place. Instead we have to
> > grep the entire tree and come up with more-or-less complex scripts to
> > figure out which bit masks are actually in use.[/color]
>
> Out of curiousity, why do we care about that list?[/color]

Originally, I used to track down IO perf issues when porting drivers to ia64.

But knowing the dma masks in use on specific platforms might allow
folks to disable DMA_ZONE (like ia64 since it's always guarateed
either a SWIOTLB or real IOMMU).

Any other uses?

thanks,
grant
[color=blue]
>
> - R.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to [email]majordomo@vger.kernel.org[/email]
> More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url][/color]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Fri, 10 Oct 2008 16:45:08 -0600
Grant Grundler <grundler@parisc-linux.org> wrote:
[color=blue]
> On Fri, Oct 10, 2008 at 11:40:56AM +0900, FUJITA Tomonori wrote:[color=green]
> > IIRC, except for one SGI architecture, coherent_dma_mask is
> > meaningless, dma_mask is always equal to coherent_dma_mask.[/color]
>
> Not correct. Several PCI-X devices can only do 32-bit DMA to control
> data but can do 64-bit DMA for payload data. I don't have the list off
> the top of my head but that is the origin of coherent DMA mask.[/color]

Thanks. I misunderstood coherent_dma_mask. I needed to read several
old mails (posted in 2002 and 2003) in ia64 mailing list.

[color=blue][color=green]
> > Lots of
> > IOMMU implementations ignore coherent_dma_mask and use dma_mask for
> > alloc_coherent().[/color]
>
> That sounds like a bug. And I don't think it's "lots".[/color]

Maybe it's not "lots" but seems that only IA64 and x86 non-hardware
IOMMU code (pci-nommu.c and GART) use coherent_dma_mask for
alloc_coherent.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

Grant prefer to add it /sys instead of showing in bootlog

so could catch if the driver set the correct dma_mask.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
drivers/pci/pci-sysfs.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

Index: linux-2.6/drivers/pci/pci-sysfs.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-sysfs.c
+++ linux-2.6/drivers/pci/pci-sysfs.c
@@ -169,6 +169,21 @@ numa_node_show(struct device *dev, struc
#endif

static ssize_t
+dma_mask_bits_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ return sprintf (buf, "%d\n", fls64(pdev->dma_mask));
+}
+
+static ssize_t
+consistent_dma_mask_bits_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf (buf, "%d\n", fls64(dev->coherent_dma_mask));
+}
+
+static ssize_t
msi_bus_show(struct device *dev, struct device_attribute *attr, char *buf)
{
struct pci_dev *pdev = to_pci_dev(dev);
@@ -223,6 +238,8 @@ struct device_attribute pci_dev_attrs[]
#ifdef CONFIG_NUMA
__ATTR_RO(numa_node),
#endif
+ __ATTR_RO(dma_mask_bits),
+ __ATTR_RO(consistent_dma_mask_bits),
__ATTR(enable, 0600, is_enabled_show, is_enabled_store),
__ATTR(broken_parity_status,(S_IRUGO|S_IWUSR),
broken_parity_status_show,broken_parity_status_store),

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:[color=blue]
> Grant prefer to add it /sys instead of showing in bootlog
>
> so could catch if the driver set the correct dma_mask.[/color]

I still don't think this is useful information to be exposing.

--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Wed, Oct 22, 2008 at 8:28 PM, Matthew Wilcox <matthew@wil.cx> wrote:[color=blue]
> On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:[color=green]
>> Grant prefer to add it /sys instead of showing in bootlog
>>
>> so could catch if the driver set the correct dma_mask.[/color]
>
> I still don't think this is useful information to be exposing.
>[/color]

RHEL 4.6 driver sata_mv is very run out of gart IOMMU, and need iommu
apterture to be 512M...
when loading is high, and it turns out every those card support 64bit
DMA, the driver DID NOT set dma to 64bit
so it still use 32 bit...

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:[color=blue]
> Grant prefer to add it /sys instead of showing in bootlog
>
> so could catch if the driver set the correct dma_mask.
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>
> ---
> drivers/pci/pci-sysfs.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> Index: linux-2.6/drivers/pci/pci-sysfs.c
> ===================================================================
> --- linux-2.6.orig/drivers/pci/pci-sysfs.c
> +++ linux-2.6/drivers/pci/pci-sysfs.c
> @@ -169,6 +169,21 @@ numa_node_show(struct device *dev, struc
> #endif
>
> static ssize_t
> +dma_mask_bits_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + return sprintf (buf, "%d\n", fls64(pdev->dma_mask));[/color]

Is there any reason to use %d instead of "0x%x" ?
I'd much rather see this dumped in hex.
[color=blue]
> +}
> +
> +static ssize_t
> +consistent_dma_mask_bits_show(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + return sprintf (buf, "%d\n", fls64(dev->coherent_dma_mask));
> +}
> +
> +static ssize_t
> msi_bus_show(struct device *dev, struct device_attribute *attr, char *buf)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> @@ -223,6 +238,8 @@ struct device_attribute pci_dev_attrs[]
> #ifdef CONFIG_NUMA
> __ATTR_RO(numa_node),
> #endif
> + __ATTR_RO(dma_mask_bits),
> + __ATTR_RO(consistent_dma_mask_bits),
> __ATTR(enable, 0600, is_enabled_show, is_enabled_store),
> __ATTR(broken_parity_status,(S_IRUGO|S_IWUSR),
> broken_parity_status_show,broken_parity_status_store),[/color]

Otherwise looks good to me.

thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Wed, Oct 22, 2008 at 09:28:33PM -0600, Matthew Wilcox wrote:[color=blue]
> On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:[color=green]
> > Grant prefer to add it /sys instead of showing in bootlog
> >
> > so could catch if the driver set the correct dma_mask.[/color]
>
> I still don't think this is useful information to be exposing.[/color]

It's useful for anyone involved with device drivers - we agree that's
a very limited subset of users. I certainly get fed up with trying
to figure out which dma_mask each driver is using since in some
cases it might vary depending on which HW is installed and which
kernel is running.

If the /sys patch added a PCI_DEBUG option to the kernel,
would that work for you?
I'm not keen on that but just looking for alternatives.
Many other subsystems (SCSI, ACPI, PM, HID, ...) have a FOO_DEBUG option.

Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
6288 6296 264893
grundler@gsyprf3:/usr/src/linux-2.6$ find /proc ! -type d | wc
find: `/proc/tty/driver': Permission denied
....
4104 4104 100797

Pruning some of the crap out of there sounds like another task suitable for
"kernel janitor" project.
/me runs and hides :)

thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Wed, Oct 22, 2008 at 11:48 PM, Grant Grundler
<grundler@parisc-linux.org> wrote:[color=blue]
> On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:[color=green]
>> Grant prefer to add it /sys instead of showing in bootlog
>>
>> so could catch if the driver set the correct dma_mask.
>>
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>>
>> ---
>> drivers/pci/pci-sysfs.c | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> Index: linux-2.6/drivers/pci/pci-sysfs.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/pci/pci-sysfs.c
>> +++ linux-2.6/drivers/pci/pci-sysfs.c
>> @@ -169,6 +169,21 @@ numa_node_show(struct device *dev, struc
>> #endif
>>
>> static ssize_t
>> +dma_mask_bits_show(struct device *dev, struct device_attribute *attr, char *buf)
>> +{
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> +
>> + return sprintf (buf, "%d\n", fls64(pdev->dma_mask));[/color]
>
> Is there any reason to use %d instead of "0x%x" ?
> I'd much rather see this dumped in hex.[/color]

that is bits, so it will be 64, 41 instead of 0xfffff

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

Grant Grundler wrote:
[color=blue]
> Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
> grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
> 6288 6296 264893[/color]

/sys is full of symlinks which /proc is not.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkkAOBwACgkQXKSJPmm5/E491ACfQHCL6A/X5bT9QVrdCFfrNe+X
x28An0aeL+VNEgmPqgETIJUkIsZ0/ydP
=WuYi
-----END PGP SIGNATURE-----

On Thu, Oct 23, 2008 at 12:44:12AM -0600, Grant Grundler wrote:[color=blue]
>
> Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
> grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
> 6288 6296 264893[/color]

Is this causing some kind of problem for your systems?

/sys shows far more information than /proc does, so of course it would
be larger in quantity.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

Greg KH wrote:[color=blue]
> On Thu, Oct 23, 2008 at 12:44:12AM -0600, Grant Grundler wrote:[color=green]
>> Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
>> grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
>> 6288 6296 264893[/color]
>
> Is this causing some kind of problem for your systems?
>
> /sys shows far more information than /proc does, so of course it would
> be larger in quantity.
>[/color]

Furthermore, it is actually structured as individual data items; a lot
of /proc files are aggregate freeform data.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Wed, Oct 22, 2008 at 11:51:36PM -0700, Yinghai Lu wrote:[color=blue]
> On Wed, Oct 22, 2008 at 11:48 PM, Grant Grundler
> <grundler@parisc-linux.org> wrote:[color=green]
> > On Wed, Oct 22, 2008 at 06:45:10PM -0700, Yinghai Lu wrote:[color=darkred]
> >> Grant prefer to add it /sys instead of showing in bootlog
> >>
> >> so could catch if the driver set the correct dma_mask.
> >>
> >> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> >>
> >> ---
> >> drivers/pci/pci-sysfs.c | 17 +++++++++++++++++
> >> 1 file changed, 17 insertions(+)
> >>
> >> Index: linux-2.6/drivers/pci/pci-sysfs.c
> >> ===================================================================
> >> --- linux-2.6.orig/drivers/pci/pci-sysfs.c
> >> +++ linux-2.6/drivers/pci/pci-sysfs.c
> >> @@ -169,6 +169,21 @@ numa_node_show(struct device *dev, struc
> >> #endif
> >>
> >> static ssize_t
> >> +dma_mask_bits_show(struct device *dev, struct device_attribute *attr, char *buf)
> >> +{
> >> + struct pci_dev *pdev = to_pci_dev(dev);
> >> +
> >> + return sprintf (buf, "%d\n", fls64(pdev->dma_mask));[/color]
> >
> > Is there any reason to use %d instead of "0x%x" ?
> > I'd much rather see this dumped in hex.[/color]
>
> that is bits, so it will be 64, 41 instead of 0xfffff[/color]

Sorry - I missed the fls64(). Looks good to me.

We only need to know if willy agrees to how/when to
limit when this is available.

thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Thu, Oct 23, 2008 at 08:39:23AM -0700, Greg KH wrote:[color=blue]
> On Thu, Oct 23, 2008 at 12:44:12AM -0600, Grant Grundler wrote:[color=green]
> >
> > Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
> > grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
> > 6288 6296 264893[/color]
>
> Is this causing some kind of problem for your systems?[/color]

Nope. Just an observation on the "forest" (vs individual "trees").
[color=blue]
> /sys shows far more information than /proc does, so of course it would
> be larger in quantity.[/color]

Yes - and /sys is better organized (hierarchial in general).
But it's getting harder to find stuff because there is so much now.
Any comments on adding DMA attributes (e.g. dma_mask_bits) to /sys?

Willy has objected and I'm waiting to hear if he's ok with limiting
this to a DEBUG compile time flag.

thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]

On Thu, Oct 23, 2008 at 01:36:52PM -0600, Grant Grundler wrote:[color=blue]
> On Thu, Oct 23, 2008 at 08:39:23AM -0700, Greg KH wrote:[color=green]
> > On Thu, Oct 23, 2008 at 12:44:12AM -0600, Grant Grundler wrote:[color=darkred]
> > >
> > > Lastly, /sys seems to have over run even /proc. On an rx2600 (ia64):
> > > grundler@gsyprf3:/usr/src/linux-2.6$ find /sys ! -type d | wc
> > > 6288 6296 264893[/color]
> >
> > Is this causing some kind of problem for your systems?[/color]
>
> Nope. Just an observation on the "forest" (vs individual "trees").
>[color=green]
> > /sys shows far more information than /proc does, so of course it would
> > be larger in quantity.[/color]
>
> Yes - and /sys is better organized (hierarchial in general).
> But it's getting harder to find stuff because there is so much now.
> Any comments on adding DMA attributes (e.g. dma_mask_bits) to /sys?[/color]

Sorry, wasn't paying attention. All I ask is that if you do add new
sysfs files, you document them in the proper format in
Documentation/ABI/

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]