Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>"loff_t" is a "long offset", i.e., a seek position that unifies the crazy diversity of <code>off_t</code>, <code>off64_t</code>, and so on, so that drivers can just use loff_t and not worry about it.</p> <p>The pointer itself, at the time you get into the driver, points to the offset provided by the user (assuming it's user code doing the driver access—technically the kernel can provide its own, but the user case is the one to think about) via <code>lseek</code> or <code>llseek</code> or <code>lseek64</code>, etc., and then by ordinary read and write operations. Consider the case of a regular on-disk file: when you first <code>open</code> the file, you (as a user) get the kernel to provide a data structure that keeps track of your current position in the file, so that if you <code>read</code> or <code>write</code> some bytes, the next <code>read</code> or <code>write</code> picks up from where you left off.</p> <p>Furthermore, if you <code>dup</code> the file descriptor, or do the equivalent by (e.g.) <code>fork</code> and <code>exec</code> in terms of running a sequence of commands, that seek-position is shared by all the inheriting processes. Hence, at the shell prompt, the command:</p> <pre><code>(prog1; prog2; prog3) &gt; outputfile </code></pre> <p>creates an output file, then <code>dup</code>s the descriptor to the three programs, so that output that <code>prog2</code> writes goes into the file immediately after the output from <code>prog1</code>, and output from <code>prog3</code> follows the other two—all because all three separate processes share the same underlying kernel data structure with the same internal <code>loff_t</code>.</p> <p>The same applies to device driver files. When your read and write functions are called, you receive the "current offset" as provided by the user, and you can (and should) update it as needed ... assuming there is any need (e.g., you want to provide users with the appearance of a regular file, including the fact that seek offsets move as you read and write). If the device has some logical application of the seek offset, you can use that here.</p> <p>Of course, there's a lot more to device drivers, which is why there are entire book-chapters on this stuff (q.v.). :-)</p>
    singulars
    1. This table or related slice is empty.
    1. POUnderstanding loff_t *offp for file_operations
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. UStorek
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POUnderstanding loff_t *offp for file_operations
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COSo when I change the offset to offset += bytes_read/write, the user pointer is changed, but it doesn't do it automatically? I think this clears some things up for me. I was reading the linux device driver 3rd edition book that everyone else reads as an intro and it had this diagram where the offset pointer was referencing some weird kernel abstraction(for lack of a better word) which they called the file position. Thanks for the help, this sort of clears things up:)
      singulars
      1. PO
      1. USDr.Knowitall
    2. COYes. (Presumably you mean `*offp += nbytes`.) The variable you're changing is actually a kernel-space thing, but it *represents* the user's seek-offset. (Or, in some cases, the offset provided to a `pread` or `pwrite` call, or even something else, but most often, the user's `lseek` offset.) That "weird kernel abstraction", as you call it, is what makes `(prog1; prog2) > output` work. Incidentally, in the *BSD kernels, there's a function called `uiomove` that automatically updates the "user I/O offset" for you; Linux just went the other way.
      singulars
      1. PO
      1. UStorek
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload