Re: "CONFIG_PROCFS" problem in 2.3.18ac8

Urban Widmark (urban@svenskatest.se)
Wed, 22 Sep 1999 22:02:21 +0200 (CEST)


This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

---1463780587-1501756850-938030261=:4387
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.9909222158451.4387@cola.svenskatest.se>

On Wed, 22 Sep 1999, Matti Aarnio wrote:

> As a side note, job for a aspiring kernel hacker:

What about aspiring perl hackers? :)

> In the system (for i386) there are now 565 'CONFIG_.*' entries and
> TWO 'IDEDMA_.*' entries. Scanning the system for such defines which
> are *NOT* defined in any configuration script file would be worthwhile
> job for somebody. Any takers ?

A simple perl hack that takes a list of files and greps them for CONFIG_,
each found is put in a hashtable of valid defines. Then search all *.[chS]
files for CONFIG_ and if not in the hash it is printed.

Is that anything like what you had in mind?

% ./cfg-scan.pl `find /usr/src/linux/ -name '*onfig.in'`
/usr/src/linux/include/linux/autoconf.h /usr/src/linux/.config

gives, on ac7:

/usr/src/linux/fs/locks.c: CONFIG_LOCK_MANDATORY
/usr/src/linux/fs/proc/root.c: CONFIG_SUN_OPENPROMFS_MODULE
/usr/src/linux/fs/proc/root.c: CONFIG_SUN_OPENPROMFS_MODULE
...

That will find a lot of bogus errors where people have used CONFIG_ for
their own defines, or things in comments.

And it is not a short list ... 1555
(with duplicates, and possibly incomplete "valid" list).

Btw, how do you count to 565 "legal" CONFIG_'s?

/Urban, waiting for someone who is good at perl to do the same in 4 lines ...

---1463780587-1501756850-938030261=:4387
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="cfg-scan.pl"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9909222157410.4387@cola.svenskatest.se>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="cfg-scan.pl"

IyEvdXNyL2Jpbi9wZXJsIC13DQojDQojIFNjYW4gZm9yIHVuZGVmaW5lZCBD
T05GSUdfIHZhbHVlcy4gSW5wdXQgYSBsaXN0IG9mIGZpbGVzIHRoYXQgY29u
dGFpbiANCiMgImxlZ2FsIiBDT05GSUdfIGRlZmluaXRpb25zLg0KIw0KIyBF
eGFtcGxlOg0KIyAgIC4vZm9vIGBmaW5kIC91c3Ivc3JjL2xpbnV4LyAtbmFt
ZSAnKm9uZmlnLmluJ2ANCiMNCg0KdXNlIHN0cmljdDsNCg0KbXkgKCVjb25m
aWcsICRzcmNkaXIpOw0KDQokc3JjZGlyID0gIi91c3Ivc3JjL2xpbnV4LyI7
DQoNCiMNCiMgQnVpbGQgYSBsaXN0IG9mIHZhbGlkIGNvbmZpZ3MNCiMNCndo
aWxlKDw+KSB7DQoJaWYoIC8oQ09ORklHX1tcd19dKykvICkgew0KCQkkY29u
ZmlneyIkMSJ9ID0gMTsNCgl9DQoJaWYoIC8oSURFRE1BX1tcd19dKykvICkg
ew0KCQkkY29uZmlneyIkMSJ9ID0gMTsNCgl9DQp9DQoNCg0KIw0KIyBDaGVj
ayB0aGUgc291cmNlcyBmb3IgQ09ORklHXydzIG5vdCBpbiB0aGUgaGFzaA0K
Iw0KbXkgKEBzb3VyY2UsICRmaWxlKTsNCg0KQHNvdXJjZSA9IGBmaW5kICRz
cmNkaXIgLW5hbWUgJ1wqLltjaFNdJ2A7DQp3aGlsZSAoJGZpbGUgPSBzaGlm
dCBAc291cmNlKSB7DQoJY2hvbXAoJGZpbGUpOw0KCW9wZW4oRkgsICRmaWxl
KTsNCgl3aGlsZSg8Rkg+KSB7DQoJCWlmKCAvKENPTkZJR19bXHdfXSspLyAp
IHsNCgkJCXByaW50ICIkZmlsZTogJDFcbiINCgkJCQl1bmxlc3MgZGVmaW5l
ZCgkY29uZmlneyIkMSJ9KTsNCgkJfQ0KCQlpZiggLyhJREVETUFfW1x3X10r
KS8gKSB7DQoJCQlwcmludCAiJGZpbGU6ICQxXG4iDQoJCQkJdW5sZXNzIGRl
ZmluZWQoJGNvbmZpZ3siJDEifSk7DQoJCX0NCgl9DQp9DQo=
---1463780587-1501756850-938030261=:4387--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/