From: Michael Richardson <mcr@sandelman.ca>
To: Greg KH <gregkh@suse.de>
Cc: linux-kernel@vger.kernel.org, bart@jukie.net
Subject: Re: odd behavior from /sys/block (sysfs)
Date: Sat, 27 Nov 2010 16:14:11 -0500 [thread overview]
Message-ID: <4605.1290892451@marajade.sandelman.ca> (raw)
In-Reply-To: <20101127185829.GA19708@suse.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Greg" == Greg KH <gregkh@suse.de> writes:
>> {please CC me}
>>
>> I was capturing data from my laptop's /sys file system as test input
>> for some code that needs to grovel through /sys a bit. I found it weird
>> that tar got different answers than ls! See below (at end) for original
>> observation.
>>
>> It seems that this is because lstat64() on sysfs returns st_size=0 for
>> the link, and tar does not know how to deal with this, while ls does.
>> I don't know if it is tar that is wrong, or sysfs.
>> lstat64(3) suggests that it is sysfs that is at fault, that it should
>> set st_size. The behaviour of ls, suggests that perhaps other systems
>> have worked around st_size=0 for symlinks. (I'm on 2.6.32-bpo.5
>> from debian)
Greg> So, what do you think should be changed here?
Iif st_size=0 is not a valid return from readlink(2), then I think sysfs
should be fixed. I will cook a patch.
While tar might not useful (I was successful at using cp -r, btw),
having working file operations makes sense.
Greg> I wouldn't ever recommend using tar on sysfs as it doesn't make any
Greg> sense (sysfs is a virtual file system, like /proc/ and I think
Greg> that tar doesn't like /proc either, right?)
Are there things on /sys for which a read is not idempotent?
On /proc, there are files which never terminate, because the process is
introspecting itself. Taking a snapshot of /sys is kinda a useful thing
if you collecting diagnostics, I think.
- --
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBTPF0nYCLcPvd0N1lAQI83Af+M5duLS+DHptiGhvE5IhVAtUdUcUrIW69
n8ipLp/c0cv8cU5pFiZrb4cv/dUDcite97CYw85WkWe28wIOjgdRgB7DxclleNLm
dgA5AzY7MSIsFL81k5lDWTiyTGx7v76DIWfMS5iMvF9lIOkX/2wG9AfQLb08AYU2
ePywvGgQtZYrXrvgPFWhFLOpmibc5v/9QqY+GhJZa56qFzsYX4OjWix7HyyYgIg+
AG1YBFowoWsFS/sw2YEaXbWivgbOfNkpo6duT03APDLoOfk+Lxb6BZWYUYY3yh0Y
4HfJiIA6XnESEqV0hGey9w6kzVoS6rn5gZmlOL81xAa3dg1JBxyd8Q==
=q414
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2010-11-27 21:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-26 18:36 Michael Richardson
2010-11-27 18:58 ` Greg KH
2010-11-27 21:14 ` Michael Richardson [this message]
2010-11-30 17:36 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4605.1290892451@marajade.sandelman.ca \
--to=mcr@sandelman.ca \
--cc=bart@jukie.net \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome