mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Peter T. Breuer" <ptb@it.uc3m.es>
To: Thunder from the hill <thunder@lightweight.ods.org>
Cc: linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: block device/VM question
Date: Tue, 27 Aug 2002 21:28:42 +0200 (MET DST)	[thread overview]
Message-ID: <200208271928.g7RJSgu12515@oboe.it.uc3m.es> (raw)
In-Reply-To: <Pine.LNX.4.44.0208271308190.3234-100000@hawkeye.luckynet.adm> from Thunder from the hill at "Aug 27, 2002 01:13:37 pm"

"A month of sundays ago Thunder from the hill wrote:"
> > And for the O_DIRECT flag we seem to do alloc_kiovec(1, &f->f_iobuf).
> 
> Perhaps we should go biovec here?
> 
> For you, if you can stand it you can even go directly into the dio stuff 
> from direct-io.c. You'll just need to know what to do. Or you fill your 
> information into some underway function.

Yes, the 2.5.31 code looks much much simpler. But you encouraged me to
look at 2.4.19 by pointing out that there has been support since 2.4.10,
so that's what I'm looking at!

I'm sure I'm just missing a couple of methods in some struct.  I'll test
a few on the way home in the train.  Things look good, just no methods to
do the work when the O_DIRECT flag is set. So I get EINVAL on every
read/write access.

I'm getting the hang of it. At every open of the device I look at the
file pointer that they're opening and check to see if it has an iobuff
field set. If not, I set it (and the O_DIRECT flag if necessary).
At every release of the device, I look at the file they're releasing
and if it has an iobuff field, I free it. I guess I should set a
flag to say "I did it", but for the moment, I guess it's only me
in the driver doing it. Kernel programming would be so much easier
if there were an explanation of what things were for :-).

I'll trace what happens in the generic_read() /write() stuff. They'll
be usiing the iobuf there.

Thanks.

Peter

  reply	other threads:[~2002-08-27 19:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.44.0208271118000.3234-100000@hawkeye.luckynet.adm>
2002-08-27 18:04 ` Peter T. Breuer
2002-08-27 19:13   ` Thunder from the hill
2002-08-27 19:28     ` Peter T. Breuer [this message]
2002-08-29  5:45 Peter T. Breuer
  -- strict thread matches above, loose matches on Subject: below --
2002-08-28 14:38 Peter T. Breuer
2002-08-27 18:40 Peter T. Breuer
     [not found] <Pine.LNX.4.44.0208271100460.3234-100000@hawkeye.luckynet.adm>
2002-08-27 17:12 ` Peter T. Breuer
     [not found] <Pine.LNX.4.44.0208271021020.3234-100000@hawkeye.luckynet.adm>
2002-08-27 16:32 ` Peter T. Breuer
2002-08-27 16:42   ` Thunder from the hill
2002-08-27 16:57     ` Peter T. Breuer
2002-08-27 11:28 Peter T. Breuer
2002-08-27  8:58 Peter T. Breuer
2002-08-27 16:06 ` Thunder from the hill
2002-08-27 16:14   ` Peter T. Breuer

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=200208271928.g7RJSgu12515@oboe.it.uc3m.es \
    --to=ptb@it.uc3m.es \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thunder@lightweight.ods.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

all inboxes | Powered by JetHome®