You need this mmap on Linux, because you don’t have Direct I/O. If you think about it, mmap() for “device files”
is really a kinda dumb, hacks, idea. It means whatever the dev wants it to mean… unlike in a file system,
where it gives you a view into the single, global, common, cache. For devices, it’s just a way to make up
for the lack of Direct I/O… to allow you to do stuff without recopying.
There are few observations to be made here
-
I don’t mean Linux in particular when speaking about " the world of the OSes that support mmap() call". This call is closely related to
“everything is a file” concept. There is the entire family of the OSes that are based upon this concept, and Linux happens to be just one of them. In fact, if you look at the whole thing from the architectural perspective, the particular implementation of mmap()
that Linux provides does not really seem to be the most architecturally-sound one in existence. If you have any doubts about this part, you can compare it to, say, SunOS/Solaris memory model. -
The “really a kinda dumb, hacks, idea” of mmap() (i.e. of providing a uniform way of mapping memory that works exactly the same way for any kind of file in existence, be it a disk file or a device one) predates Linux 0.01 by more than two decades. Furthermore, it predates not only Linux but UNIX as well. This concept is rooted in MULTICS - this is where the very idea of user apps attaching/detaching memory segments that are backed up by a store to/from their address spaces comes from.
In actuality, mmap() as we know it is just a result of combining this concept with “everything is a file” one. As you may have guessed, this
“merger” had been pioneered by SunOS. In fact, the very term “segment drivers” seems to make a very unambiguous reference to MULTICS
origins (at least the conceptual ones) of memory mapping, don’t you think…
-
The very concept of METHOD_DIRECT has absolutely nothing to do with sharing a buffer between an app and a driver
(and least it was not originally meant to be used this way). You must be confusing it with METHOD_NEITHER that was, indeed,
intended specifically for this purpose from the very beginning of “Windows NT world”. What actually happened here is that some clever bloke (I guess it was you, right) realised that, by pending METHOD_DIRECT-based IOCTL indefinitely one effectively gets a shared buffer
while, at the same time, avoiding all the extra pain in the arse that METHOD_NEITHER implies. As a result, the concept of a “Big Honking IRP” was born -
In case if you just cannot imagine your life without above mentioned “Big Honking IRPs” (you seem to be particularly fond of them these days, aren’t you), I can assure you that you can implement them under Linux just in a click of fingers.
All you have to do is to mlock() your target buffer before passing its address to a driver. In response to your app’s request, your driver will validate the address of every page in the target range, get its ‘struct PAGE’ descriptor, reference it, and then map all the target pages to the virtually contiguous kernel range with vmap(). At this point you driver will be able to access the shared buffer in any context, and it is 100% safe. Certainly, taking into consideration the availability of mmap() this is, probably, not the most efficient and reasonable way of doing things under Linux, but this is already a different story.
In other words, your “argument” about “needing this mmap on Linux, because you don’t have Direct I/O” simply
does not stand a slightest chance…
In terms of ad hominem attacks… pointing out your lack of actual recent experience on Windows is just something
a questioner here should consider… it’s just a fact and not ad hominem at all.
Actually,I don’t really find the very fact of " lacking of actual recent experience on Windows" embarrassing in any possible way.
After all, I had mentioned this fact quite a few times in this NG.
The only thing that I am saying here is that you somehow found a way to use this fact as an “ad hominem” attack. In the end of the day,
sometimes this is not about WHAT you had actually said but more about HOW you had said it. Let’s look at your statement one more time
[begin quote]
Bear in mind that Anton hasn’t written any code on Windows for about ten years. He just hangs out here for the abuse.
[end quote]
I hope you agree that the above statement in its actual form is a very obvious example of “ad hominem” argument, and was meant to be used as the one…
Anton Bassov