lshwd 2.0

z4ziggy · 2005-05-28 15:20:10

hey all.

im reworking lshwd to provide subvendorid/subdeviceid parameters for some weird hw support. as a result, i was thinking of loosing the pciutils/usbutils packages dependency and format /proc/bus/xxx myself. this will enhance lshwd to be able to work from initrd/etc... only drawback i see is the direct use of /proc/bus/xxx info where i've read somewhere its not encouraged - however, the pcilib/usblib are doing just the same...

so, any comments? and thank you all for your support

phrakture · 2005-05-28 16:36:14

if you need the proc filesystem, you can't run from an initrc, because proc won't be mounted....

but there's probably a way to emulate the same output

z4ziggy · 2005-05-28 16:41:57

usually you'll mount /proc in initrd (from initrc) too except for initrd prompt only (ie, no booting from hw-devices which must be enumed using /proc).

but what u think? any drawbacks for using /proc directly?

i3839 · 2005-05-28 16:45:49

Only drawback is that it's more work for you, but that's all. That said, if I were you I'd go for it, I don't like unneeded dependencies much.

z4ziggy · 2005-05-28 19:50:48

i dont care much for the extra work (i actually used /proc/bus/usb in older versions ) so its not gonna take long anyway (hopefully).

well, unless ppl find any other drawbacks, consider less dependencies on lshwd 2.0

i3839 · 2005-05-28 20:08:02

lspci and lsusb are less than 100K though, while pci.ids and usb.ids are almost 350K, so it looks like it isn't worth it much.

You say that currently hwd can't work from initrd, why do you think that is the case?

z4ziggy · 2005-05-28 20:20:00

if i drop lspci & lsusb, there is no need for the *.ids files any longer. also, the main reason for loosing the libs is to simplify lshwd - formatting /proc/bus/xxx is fairly easy imo.
lshwd can be used in initrd - its simply a matter of space - reducing dependencies will help with this.

i just dont see much reason anymore for using the libs if /proc is just sitting waiting to be probed...

i3839 · 2005-05-28 21:18:00

Hm, indeed, you don't need most info in those *.ids files, only the id-->module mappings, which can be found in /lib/modules/`uname -r`/modules.* anyway.

As a total sidenote, are you aware of the recent hotplug developments? Mainly passing on the module alias directly instead of the slow /sys parsing which happens now? If those are stored somewhere in /sys so that coldplugging and just viewing them is possible then there's no need for any complicated stuff anymore. Ever considered helping to improve hotplug instead of making a sort of alternative?

z4ziggy · 2005-05-28 22:40:01

i admit shamelessly, i did take a look at hotplug sources - but its a huge project, and will take me sometime to learn it, not to mention - im lazy, hate hotplug, and used lshwd as a starting point for my linux programming experience...

all and all, i think i'll give /proc/bus/xxx a go

ps.
i just remembered, im using "/proc/bus/ieee1394/devices" anyway for firewire probing... so we're one foot in it already

i3839 · 2005-05-28 23:11:45

They seem to be moving from /proc to /sys though, at least in the long run. I'd take a good look at sys, perhaps it can make some things easier.

Hotplug isn't that big, it's just a bunch of shellscripts. pacman -Ql hotplug output isn't that intimidating. I'm not talking about the (real) hotplug implementation in the kernel, but for you the only interesting part is the kernel-usermode interface anyway (/sbin/hotplug + environment vars).

z4ziggy · 2005-05-29 00:39:18

sorry, i thought u ment the complete hotplug kernel-stuff sources. anyway, the i might look into improving hotplug later on, but i think lshwd has a niche for itsown, and i better fix it 1st.

regarding /sys vs /proc - any pros/cons ? they seems to provide same level of data, but in different formats.

Dusty · 2005-05-29 00:58:04

improve lshwd, apply what you learned to hotplug. :-)

IIRC, it says in the kernel that /proc is 'legacy support'. This means it will be removed someday. I suppose its replaced by /sys?

Arch tends to be bleeding edge, so /sys would win if this is the case.

Dusty

iphitus · 2005-05-29 03:34:53

Proc certinly isnt obsolete or dated. and there is no mention of it being such in it's entry under Filesystems > Pseudofilesystems.

What you're thinking of is the entry for /proc/scsi/ which is under scsi, which is called 'legacy /proc/scsi support' which indicates that the scsi entry in proc has been superseded by the entries in /sys.

Either way, proc is unlikely to be removed anytime soon, and probably not in 2.8 either, it'll be here to stay for a while.

iphitus

Dusty · 2005-05-29 03:46:53

iphitus wrote:

What you're thinking of is the entry for /proc/scsi/ which is under scsi, which is called 'legacy /proc/scsi support' which indicates that the scsi entry in proc has been superseded by the entries in /sys.

I doubt that's what I was thinking of because I never touched scsi before. But I don't remember what it was I was thinking of if that's the case, its been a long time since I compiled a kernel.

Dusty

z4ziggy · 2005-05-29 08:00:09

i read all docs under Documentation/filesystems/ regarding procfs/sysfs and couldnt find any mention of "obsolete" or "outdated". only difference is procfs is dated from 2000, and sysfs from 2003.

since both fs are used in all distros i know (please correct me if im wrong on this...) i cant see much difference in using any of them.

just 1 small remark - it seems /proc will be quicker to parse, but its only from 1st glance. i might be wrong on this also...

i3839 · 2005-05-29 09:59:37

/sys is linux 2.6 only. The main goal of /sys is to clean up /proc and move all hardware related and driver specific info into it, so that /proc is used for what it was meant to originally. In /sys all files have one value, making parsing it peanuts, though instead you may need to do readdir more often. New hardware will have sys support, and things are moved from /proc to /sys, so in the long run /proc will have no hardware info anymore, but that will take a while (2.7 I guess). /sys seems to have more info than /proc, making it harder to figure out which part you need. So for now use whatever you want, but keep in mind that you may need to look in /sys for certain hardware.

z4ziggy · 2005-05-29 10:31:25

tnx for the explanation, i highly needed that.

i think the best is to make lshwd procfs compatible, while keeping in mind future sysfs use. once we have complete "parsing engine" i guess we could adopt it to sysfs easily enough (we might keep them both...).

request:
i seems to lost old lshwd sources (0.3) so if anyone might has them i'd appreciate it. i dont feel like recoding the usb parsing part which was on 0.3 but removed on 0.4 in favor of usbutils...

lanrat · 2005-05-29 14:49:51

I think I've found something which looks like 0.3 sources :-)

I've tared and gzipped the files and you can download it here:
http://lanrat.webpark.pl/lshwd-03.tar.gz

Dusty · 2005-05-29 17:12:45

put it under version control, you goof!

Dusty

z4ziggy · 2005-05-30 01:00:08

kisses kisses

and we did have webcvs in user-contributions, but for some reason its gone, and Rasat is on another of his travels...

z4ziggy · 2005-06-04 00:19:50

i took some time to learn more about sysfs, and it simply THE bomb... standardized like one expects an information filesystem to be. though i finished removing the usbutils/pciutils dependencies from lshwd and changed to parsing /proc/bus/usbpci instead, i admit using the sysfs would have been a better step...

but hey - thats just a good reason as any for having a 3.0 version! :twisted:

i3839 · 2005-06-04 10:56:22

Oh well, tried to inform you about sysfs before you wasted time on /proc, but now you've something to look forward to. ;-)

z4ziggy · 2005-06-04 12:51:40

pixel · 2005-06-04 23:47:12

z4ziggy, you might check this thread
http://bbs.archlinux.org/viewtopic.php?t=12070

z4ziggy · 2005-06-05 01:30:23

8)

lshwd 2.0 is finished. only 1 question before releasing it (not yet as pkgbuild to allow Rasat to return from abroad and adopt hwd) - i dropped pcmcia detection since from what i've learned all pcmcia devices are listed under /proc/bus/pci anyway (and so they did on my testings also). i'd like to confirm this please if you may, just so i can know i didnt drop an important function... as a result, no need for pcmciatable anymore since the devices listed as pci will be found in pcitable

anyway, just confirmation and 2.0 is released

Arch Linux

#1 2005-05-28 15:20:10

lshwd 2.0

#2 2005-05-28 16:36:14

Re: lshwd 2.0

#3 2005-05-28 16:41:57

Re: lshwd 2.0

#4 2005-05-28 16:45:49

Re: lshwd 2.0

#5 2005-05-28 19:50:48

Re: lshwd 2.0

#6 2005-05-28 20:08:02

Re: lshwd 2.0

#7 2005-05-28 20:20:00

Re: lshwd 2.0

#8 2005-05-28 21:18:00

Re: lshwd 2.0

#9 2005-05-28 22:40:01

Re: lshwd 2.0

#10 2005-05-28 23:11:45

Re: lshwd 2.0

#11 2005-05-29 00:39:18

Re: lshwd 2.0

#12 2005-05-29 00:58:04

Re: lshwd 2.0

#13 2005-05-29 03:34:53

Re: lshwd 2.0

#14 2005-05-29 03:46:53

Re: lshwd 2.0

#15 2005-05-29 08:00:09

Re: lshwd 2.0

#16 2005-05-29 09:59:37

Re: lshwd 2.0

#17 2005-05-29 10:31:25

Re: lshwd 2.0

#18 2005-05-29 14:49:51

Re: lshwd 2.0

#19 2005-05-29 17:12:45

Re: lshwd 2.0

#20 2005-05-30 01:00:08

Re: lshwd 2.0

#21 2005-06-04 00:19:50

Re: lshwd 2.0

#22 2005-06-04 10:56:22

Re: lshwd 2.0

#23 2005-06-04 12:51:40

Re: lshwd 2.0

#24 2005-06-04 23:47:12

Re: lshwd 2.0

#25 2005-06-05 01:30:23

Re: lshwd 2.0

Board footer