From: marcov@stack.nl
On 2005-06-03, John Smith wrote:
> Yep, used to have to do it... you take time slices from a processor
> which is already time slicing,
What where how ? Anything I do takes timeslices. However it takes them from
the OS scheduler, not the processor. What are you talking about anyway ?
> you have to synchronize to get good
> performance,
What synchronization, where, how? I don't have to synchronize for a kernel
call. The kernel scheduler will block if necessary, and will unblock if
needed. Nothing async about it that needs syncing.
> you force overhead on the processor to push and pull registers on its
> stack...
That's needed for every IPC call, including kernel. The kernel will handle
did, if needed at all, since usually regs are not already saved for
parameter transfer.
> and there are strict rules to doing it successfully enough to be
> able to turn out a retail product... if you are just hacking about--a
> crash now and then is no real problem...
That's so general in software development, that it applies to pretty much
everything. It is like saying that water is wet.
> Most when they first learn enough assembly to be dangerous see
> everything as an assembly problem,
Of course. But calling the kernel directly from userland usually pretty much
is an problem to which assembler is at least relevant. OS ABI etc.
Moreover it was just as example that other OSes also use ints (read: kernel
calls), that the principle is not dos-specific at all.
> after about 20 years of professional
> paid programming and gaining senior status, you spend a lot of time
> doing such things...
What things? Recognizing a system call? Ranting about sites without actually
reading what it is about?
> Most of the time, you will want to call kernel code and let the
> processor handle things for you,
Well, that is pretty much logical for a system call isn't it? Specially
if a different name for syscall is _KERNELCALL_.
> usually much more efficient unless you have a team of senior programmers
> you can spare...
A kernel call is totally separate from performance or processor. It is about
privilege levels.
> only time assembly is a real shinning star is the example
> I provided--that is, when there is simply no other way to accomplish the
> task, in windows the api is very complete
Assembly and API use are not correlated. Specially since the assembler site
I referenced _is_ about calling the kernel (hence API)
>... if you just built a new printer, scanner, camera, mp3 device, etc...
> you will need at least the ddk to begin and possibly, you may even need to
> drop to assembly to accomplish a task
The whole point of the ddk is to not make that 100% necessary. Still can
be important out of performance reasons though for high speed devices, but
that must be a decision based on profiling.
>... in linux there are similar libraries which are available from 3rd party
> vendors
Linux.... 3rd party vendors ... ? For bloody what? Driver (read: Kernel
module) enhancement? Which third party vendor makes linux then do you think?
:) The whole kernel src is available and that is the DDK at the same time.
> which have been well road tested and debugged... Warmest regards,
I wonder if you even have a clue about Linux (or *nix in general) at all.
If I seem harsh, it is because your message was a totally useless rant, with
clear indication that you didn't even bothered to look or try to understand
what I was saying.
The fact that you haven't contributed anything useful yet in all your msgs
is also not helping, as is your top-posting
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
