I think procfs is definitely the wrong place. It should have process specific stuff only. I even think that new procfs entries will be rejected in the mainline kernel.
I know there is some stuff in procfs right now that isn't process specific, but I have also seen patches rejected because they put stuff in procfs that was not process specific. Usually these ended up in sysfs. -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Edmund R. MacKenty Sent: Thursday, October 13, 2005 10:06 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks Fargusson.Alan writes: >But it isn't a device is it? It isn't a filesystem either. > >It looks like sysfs is the best fit even if it isn't really the right >place for it. Actually a architecture specific system call might be the >right thing to do, but I suspect it would be hard to get it implemented. Yeah, sysfs is supposed to expose devices and other kernel objects, not provide arbitrary interfaces to kernel modules. But one could argue that CP (or DIAG) is the "object" we're communicating with via an entry in sysfs (or procfs). We're exposing a way to communicate with that object with an entry in the sysfs. Is that too much of a stretch? - MacK. ----- Edmund R. MacKenty Software Architect Rocket Software, Inc. Newton, MA USA ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390