Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Not knowing the /proc file system

admccartney.mur.at

Post reply on HN
Print view View original

21–30 of 111 posts

Re: Not knowing the /proc file system

#21

Post by themulticaster »

ahoka wrote: post #17
Animats wrote: post #6

The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…

“The Linux kernel has no standard mechanism for delivering a variable-sized result from a system call.” In NetBSD you can create XML serialized system calls for this. :-)

Of all the BSDs, I'm only a little familiar with OpenBSD through its OpenSSH fame, so I'm a little surprised to hear that a (probably) somewhat related project would use XML in a system call. In other words, if an OpenSSH release introduced XML as a wire format I'd assume it to be an April fools's joke. [1] But I guess OpenBSD and NetBSD are less related than I thought.

Re: Not knowing the /proc file system

#22

Post by IggleSniggle »

dezgeg wrote: post #20
9dev wrote: post #2

Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. Are you guys still coding in Notepad and need to conserve keystrokes, or where does that reluctance to use proper names come from?

Because for some reason many C programmers still insist on 80-character line length limit and 8-wide tab indentation, so something has to give to fit all on the screen

8-wide tab is still just 1 char of your 80 allotted. Just sayin'.

Re: Not knowing the /proc file system

#23

Post by Someone »

Animats wrote: post #6

The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…

> If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions

AFAIK, as that StackOverflow page also says, that’s not guaranteed to be possible. https://man7.org/linux/man-pages/man2/read.2.html:

“RETURN VALUE

On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number.

It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal”

I think you can avoid the “because read() was interrupted by a signal” part by not installing signal handlers, but even if that’s an option for you, that list isn’t exhaustive.

Your best bet is to pass the maximum supported number for count to the call (SSIZE_MAX in POSIX, 0x7ffff000 on Linux, and hope that the call returns all bytes.

Luckily, I think that will be fine most of the time, but that doesn’t mean /proc is a good idea.

Re: Not knowing the /proc file system

#24

Post by rascul »

lifthrasiir wrote: post #7
9dev wrote: post #2

Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. Are you guys still coding in Notepad and need to conserve keystrokes, or where does that reluctance to use proper names come from?

Maybe your tangent is pointing at a wrong direction, because I think there are also a sizable portion of such programmers in many other languages. It seems that anOverlyLongAndInformationFreeIdentifier is widely despised, but once names do have enough information contents, an exactly preferred name wildly varies even in a single code base. For example induction variables in Python generators tended to be shorter than…

> anOverlyLongAndInformationFreeIdentifier

Apple has one 82 characters.

https://developer.apple.com/documentation/contacts/cnlabelco...

Re: Not knowing the /proc file system

#25

Post by linuxftw »

I use the /proc file system all the time. Often containers don't have ps or several other tools installed, so you can use /proc to find out how a process started, open file descriptors, open sockets, and a bunch of other information. In fact, many user-space tools like netstat are just purpose-built readers of things in /proc.

Re: Not knowing the /proc file system

#26

Post by Rapzid »

Animats wrote: post #6

The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…

TIL "real" fs calls aren't system calls..

I'm not disputing there are issues but that's a very misleading description of the implementation.

Re: Not knowing the /proc file system

#27

Post by RhysU »

dale_glass wrote: post #4
9dev wrote: post #2

Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. Are you guys still coding in Notepad and need to conserve keystrokes, or where does that reluctance to use proper names come from?

Just inertia from the times where teletypes were a thing. As in, a mechanical printer that served as your console. When you have that as your interface you want to keep things terse. Even after that you had compilers with limits like 6 character names for a symbol. Those constraints went away, but names made to be comfortable for the users of teletypes and ancient compilers stuck around, and people made more of them…

As a lingua franca, it's culturally reasonable.

After you've grokked it the first time, e.g. "dgemm" is much more convenient than "double precision general matrix multiplication". This is akin to speaking aloud "DC" versus "The District of Columbia". Uses far outweigh learning.

Consider even Python calls it a "dict" not a "dictionary" because the latter is a mouthful. Though what was wrong with "map" I often wonder.

Re: Not knowing the /proc file system

#28

Post by xyzelement »

rascul wrote: post #24
lifthrasiir wrote: post #7

Earlier quoted context omitted.

Maybe your tangent is pointing at a wrong direction, because I think there are also a sizable portion of such programmers in many other languages. It seems that anOverlyLongAndInformationFreeIdentifier is widely despised, but once names do have enough information contents, an exactly preferred name wildly varies even in a single code base. For example induction variables in Python generators tended to be shorter than…

> anOverlyLongAndInformationFreeIdentifier Apple has one 82 characters. https://developer.apple.com/documentation/contacts/cnlabelco...

And I would say that’s a good case where the long name is meaningful and necessary.

On the other hand when you are dealing with a file pointer in a language that deals with file pointers constantly, “fp” is meaningful enough.

Re: Not knowing the /proc file system

#29

Post by williamcotton »

jstanley wrote: post #12
9dev wrote: post #2

Tangent: Looking at those code samples, I wonder whether coming up with the shortest possible, most cryptic variable names is somewhat of a sport amongst C developers. Are you guys still coding in Notepad and need to conserve keystrokes, or where does that reluctance to use proper names come from?

What specifically are you referring to? Do you mean like using `fp` for a file pointer or `fd` for a file descriptor? That is idiomatic, and I would consider calling them `filePointer` or `fileDescriptor` to be an obvious smell that the developer doesn't know what they're doing.

I beg to differ... slightly!

I'll do something like:

  int epollFd = epoll_create1(0);
So yes, I don't think I have ever typed out "fileDescriptor" but I do label these things to make it more legible!

OP has a point. We could do with more discipline when it comes to naming conventions in C. We're not using punch cards any longer.

Somewhat related, there's another comment about the 80 char max... clang-format keeps to this. I'm kind of OK with this particular remnant of punch cards because I can get four editor windows open side by side on my ultra wide monitor.

The nginx codebase is pretty freaking fantastic and I've learned a lot from just randomly browsing through the source, but I mean, come on:

https://github.com/nginx/nginx/blob/master/src/core/ngx_arra...

  if ((u_char *) a->elts + a->size * a->nalloc == p->d.last) {
What's p? Oh, ngx_pool_t. Object pool? Memory pool? What's a again? elts? Is that elements?

If that read:

  if ((u_char *) array->elements + array->size * array->nalloc == memoryPool->d.last) {
It's time for the old school conventions to change a little bit. C ain't going anywhere. Let's embrace a world where descriptive variable names are not subject to cost/benefit analysis like they were in 1977.

Re: Not knowing the /proc file system

#30

Post by dale_glass »

RhysU wrote: post #27
dale_glass wrote: post #4

Earlier quoted context omitted.

Just inertia from the times where teletypes were a thing. As in, a mechanical printer that served as your console. When you have that as your interface you want to keep things terse. Even after that you had compilers with limits like 6 character names for a symbol. Those constraints went away, but names made to be comfortable for the users of teletypes and ancient compilers stuck around, and people made more of them…

As a lingua franca, it's culturally reasonable. After you've grokked it the first time, e.g. "dgemm" is much more convenient than "double precision general matrix multiplication". This is akin to speaking aloud "DC" versus "The District of Columbia". Uses far outweigh learning. Consider even Python calls it a "dict" not a "dictionary" because the latter is a mouthful. Though what was wrong with "map" I often wonder.

> Consider even Python calls it a "dict" not a "dictionary" because the latter is a mouthful. Though what was wrong with "map" I often wonder.

A conflict with the map() function maybe?

Post reply on HN