Re: apmd and other archs

On Thu, Nov 23, 2000 at 11:40:15AM +0100, Michel Dänzer wrote:

quoted

quoted

quoted

/proc/apm and /dev/apm_bios are so simple that it should be easy to
convince any power management system to provide those API's.

The info logged to /proc/apm is currently logged to /etc/power/apm. I

Is this a typo?  Why is status information in /etc?

Because it's from pmud, which can't create /proc entries.

Then it should go in /var, I think.  We have standards for this stuff.
(FSSTND, FHS, Debian policy.)  I might want to mount /etc read-only (and
/usr too, while I'm at it)... and this sounds like it would prevent me from
doing so.

Thanks,

Avery


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

quoted

quoted

The info logged to /proc/apm is currently logged to /etc/power/apm. I

Is this a typo?  Why is status information in /etc?

Because it's from pmud, which can't create /proc entries.

Then it should go in /var, I think.  We have standards for this stuff.
(FSSTND, FHS, Debian policy.)  I might want to mount /etc read-only (and

Granted. pmud was first packaged for LinuxPPC which is rpm based and cares
about FHS about as much as RedHat does. I'll look for a better place to
stick the fifo.

Re: mounting /etc readonly: how do you handle /etc/mtab in that case? :-)

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 23 Nov 2000, Avery Pennarun wrote:

Then it should go in /var, I think.  We have standards for this stuff.
(FSSTND, FHS, Debian policy.)  I might want to mount /etc read-only (and
/usr too, while I'm at it)... and this sounds like it would prevent me from
doing so.

On Thu, 23 Nov 2000, Michael Schmitz wrote:

Granted. pmud was first packaged for LinuxPPC which is rpm based and cares
about FHS about as much as RedHat does. I'll look for a better place to
stick the fifo.

Re: mounting /etc readonly: how do you handle /etc/mtab in that case? :-)

	Michael

I agree that power management status/log should go to /var. On the other
hand /etc has to be on the root fs for several reasons (/etc/inittab among
others is quite important): IOW you don't use a separate mount point for
/etc unless you want to play dirty tricks with init.

Of cuorse there is a precedent for modifying /etc: /etc/mtab, but
admittedly for good reasons. mount also puts lock files in /etc and has to
have these funky option (-n and -f) to work around the chicken and egg
problem of initial read only root filesystem mount by the kernel. Once you
have these option I don't see any reason not to have /var/mtab instead for
example but maybe I miss something.

Now /etc/mtab is also somewhat redundant with /proc/mounts. Actually you
should be able to link /etc/mtab to /proc/mounts but it raises a lot of
problems and does not work satifactorily in my experience.

I have a setup of a lot of different diskless machines which share
basically everything: /usr and /home on the same mount point, and almost
all files in the root directories are hardlinked, except for files in
/etc and /var, where it turned out to be impossible (and I don't mind an
additional megabyte or so of disk space per diskless system, it's still
about 99.9% shared).

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 5:37 AM -0600 11/23/2000, Gabriel Paubert wrote:
[...]

I agree that power management status/log should go to /var. On the other
hand /etc has to be on the root fs for several reasons (/etc/inittab among
others is quite important): IOW you don't use a separate mount point for
/etc unless you want to play dirty tricks with init.

Of cuorse there is a precedent for modifying /etc: /etc/mtab, but
admittedly for good reasons. mount also puts lock files in /etc and has to
have these funky option (-n and -f) to work around the chicken and egg
problem of initial read only root filesystem mount by the kernel. Once you
have these option I don't see any reason not to have /var/mtab instead for
example but maybe I miss something.

Now /etc/mtab is also somewhat redundant with /proc/mounts. Actually you
should be able to link /etc/mtab to /proc/mounts but it raises a lot of
problems and does not work satifactorily in my experience.

[...]

I think technically the /proc filesystem is optional. Requiring /proc for
mount to function gives you another fun chicken + egg of how the heck do
you then mount /proc on startup? ;)

At the risk of drifting way off topic, it might be worth looking at
rewriting mount and fellow /etc/mtab users to just never need to use a file
like /etc/mtab. I can particularily recall a few times where a stale,
unwritable /etc/mtab made some system reconfiguration and/or system
recovery about 5 times more annoying than it needed to be.

30 years of unix tradition be damned, /etc/mtab sucks.


As for pmud, why not use a socket interface for everything? Using loopback
tcp  in one place and a file in another place seems a bit silly to me.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 23 Nov 2000, Tony Mantler wrote:

quoted

Now /etc/mtab is also somewhat redundant with /proc/mounts. Actually you
should be able to link /etc/mtab to /proc/mounts but it raises a lot of
problems and does not work satifactorily in my experience.

[...]

I think technically the /proc filesystem is optional. Requiring /proc for
mount to function gives you another fun chicken + egg of how the heck do
you then mount /proc on startup? ;)

Because mount stats /etc/mtab and does not touch it if it finds that it is
a symlink. But this has still problem, I just can't remember which ones. I
know that I thought it would be great and had to go back to the standard
/etc/mtab.

Indeed proc is optional, but in practice it has become a necessary evil.
Most systems won't boot without it, hey most init scripts now have a look
at /proc/cmdline and whatnots. Ugly as hell...

At the risk of drifting way off topic, it might be worth looking at
rewriting mount and fellow /etc/mtab users to just never need to use a file
like /etc/mtab. I can particularily recall a few times where a stale,
unwritable /etc/mtab made some system reconfiguration and/or system
recovery about 5 times more annoying than it needed to be.

30 years of unix tradition be damned, /etc/mtab sucks.

Indeed.

	Cheers,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Gabriel Paubert wrote:

Because mount stats /etc/mtab and does not touch it if it finds that it is
a symlink. But this has still problem, I just can't remember which ones. I
know that I thought it would be great and had to go back to the standard
/etc/mtab.

See http://www.xss.co.at/sysinfo/mounts.html

- Adrian Cox, AG Electronics

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 23 Nov 2000, Adrian Cox wrote:

Gabriel Paubert wrote:

quoted

Because mount stats /etc/mtab and does not touch it if it finds that it is
a symlink. But this has still problem, I just can't remember which ones. I
know that I thought it would be great and had to go back to the standard
/etc/mtab.

See http://www.xss.co.at/sysinfo/mounts.html

Thanks for the pointer. Now that I see it, I remember that the major
problem I had on the diskless machines was that /proc/mounts did not have
enough information, especially for the root mount point when it is an NFS
mount. The root mount point always appears as /dev/root BTW.

	Thanks,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/