[HN Gopher] Windows 11 Insider Preview Build 25905 brings a bit ...
___________________________________________________________________
Windows 11 Insider Preview Build 25905 brings a bit of Rust in the
kernel
Author : pjmlp
Score : 68 points
Date : 2023-07-12 19:06 UTC (3 hours ago)
(HTM) web link (blogs.windows.com)
(TXT) w3m dump (blogs.windows.com)
| TillE wrote:
| It'd be really exciting if they make a safe Rust API for kernel
| drivers. You can technically write a driver in Rust, but the bulk
| of your code will be interacting with the unsafe, complex C API,
| so it's a bit pointless.
| nikanj wrote:
| And that unsafe, complex C API communicates with an even
| sketchier system made of registers, IO ports and nasty hardware
| details. Providing a higher level API for a nastier backend has
| always been a core feature of operating systems and programming
| languages.
| tialaramex wrote:
| Almost nothing is still I/O ports because it's more portable
| to use MMIO and if you're going to offer MMIO why bother also
| doing I/O ports. But yes, as a vague outline you're correct.
| martin8412 wrote:
| You'd need some kind of formal model of the hardware for that
| to be feasible. A big part of doing driver development is
| writing strings of bits to hardware addresses over I2C, SPI,
| USB or other protocols.
| None4U wrote:
| Maybe on the hardware side, but the way we communicate that
| to Windows can still be under Microsoft's control
| eptcyka wrote:
| One could make the same point about any rust that ultimately
| interfaces with the system using libc - all Rust programs at
| one point were interfacing with a lot of C code.
|
| A more serious counter argument is that Mozilla did exactly
| this with Rust in Firefox - and it seems to be a success,
| there's still lots of Rust in the browser and it seemingly is
| working.
|
| Point being, using Rust for all of the things will probably be
| painfully cumbersome today, but writing up a complicated enough
| component with a well defined boundary with the rest of the
| kernel will probably prove immensely useful and won't be
| painfully cumbersome.
| pjmlp wrote:
| It doesn't change the point being made in regards to safety,
| however Windows kernel drivers nowadays tend to use C++, not C.
|
| There is even a template library for it, Windows Implementation
| Libray, WIL.
| steveklabnik wrote:
| Some previous discussions on this:
|
| * https://news.ycombinator.com/item?id=35729655
|
| * https://news.ycombinator.com/item?id=35924008
| terandle wrote:
| My favorite bit was they fixed Zune support
|
| "In celebration of Marvel Studio's Guardians of the Galaxy Volume
| 3, we temporarily re-launched Zune.net last month. We also took
| the opportunity to fix an issue that was causing some challenges
| in getting the original Zune drivers to install in Windows 11
| with this build in the Canary Channel. So now it should be easier
| to use your (totally unsupported and still discontinued) Zune on
| Windows 11."
| slenk wrote:
| Wait...will I actually be able to plug my ancient Zune back in?
| I am pretty sure I have the cable yet.
|
| Just hard to tell what's sarcasm on the internet now.
| ChuckNorris89 wrote:
| I didn't get the point of using a Zune in the latest Guardians
| movie. Why the product placement for a product that's long
| discontinued? Microfot won't make any money if people go on
| ebay and buy a used Zune out of nostalgia. Or it wasn't a
| product placement after all?
| dudeinhawaii wrote:
| It wasn't a product placement any more than a Sony Walkman
| was a product placement...
|
| It was a joke, like saying, "You're finally with the times.
| Drop your tape deck, here's a Zune!" It wouldn't have landed
| the same way with an iPod.
| nwah1 wrote:
| It is a joke.
| andrewstuart wrote:
| If rust is complex and hard to learn, doesn't this make it a bad
| idea for use in a kernel?
|
| Shouldn't readability/ understandability be a critical
| requirement for kernel code?
| hn92726819 wrote:
| It's two different concepts. 1) hard to learn 2) hard to
| read/understand
|
| I would argue rust is hard to learn, and not hard to read or
| understand once you know it. In my opinion, for example:
|
| Hard to learn, easy to read: Rust Easy to learn, hard to read:
| Perl Hard to learn, hard to read: C++ Easy to learn, easy to
| read: Python
|
| Even if you don't agree exactly with my opinions, you could
| maybe see the distinction between (easy/hard to learn) and
| (easy/hard to read, once you learned it).
|
| I also think that 99% of the difficulty in learning rust is
| learning how to get to a compiled state. Once the binary is
| built, you can make a lot more assumptions about it than other
| binaries (for example, locations of crashes, overflows,
| ownership, memory freeing can all be detexted). Compare that to
| c or c++ where getting to a compiled state is way easier, but
| the resulting binary segfaults or other issues.
| Skunkleton wrote:
| Dunno if you can/should edit it, but at first glance I read
| that as C++ being easy to learn and easy to read.
| fndex wrote:
| One could argue that C++ is much more complex and hard to write
| correct code.
| andrewstuart wrote:
| Pointing at C++ as bad doesn't address my point.
|
| Kernel code should be easily readable and understandable,
| shouldn't it?
|
| If Rust is complex and hard to understand won't that lead to
| the kernel source code becoming a giant kablooie of
| complexity?
|
| Surely the relatively simple nature of C is what makes it
| suitable for large scale kernel development.
|
| Maybe the answer for more secure kernel code is C with better
| security analysis tools?
| dist-epoch wrote:
| C has too little abstractions, which means you need more
| code to express the same things as Rust.
|
| And the number of bugs per line of code is constant, so you
| will have more bugs in C code than in Rust code simply
| because you'll have more code.
| onei wrote:
| Hard to learn does not necessarily equate to hard to read.
| You don't need to learn to work with Rust's borrow checker
| to understand a bit of code, but figuring out how to change
| it might take longer.
| TypesWillSaveUs wrote:
| You're conflating hard/easy and complex/simple.
|
| Rust is hard/simple. The rules aren't complex. The
| constructs aren't complex. But it's hard to write because
| the rules are very restrictive.
|
| Rust is also much easier to read than write (for a reader
| who understands the rules).
|
| It's optimising for exactly the things you want in systems
| programming:
|
| Easier to read than the write. Simple rules that are easy
| to understand but hard to follow, and that produce simple
| programs.
|
| Compare that to C which is easy/complex. It's much easier
| to write than to read. It's easy to learn and write but
| produces code that's very complex. The rules are all by
| convention instead of part of the type system.
| andrewstuart wrote:
| >> for a reader who understands the rules
|
| So you're saying it's not a problem to understand if you
| understand it.
| bbatchelder wrote:
| Think of chess.
|
| Its pretty easy to learn the rules. Once you've done that
| you can watch a game and know roughly what is happening.
| But its still a hard game to master.
| aleph_minus_one wrote:
| > One could argue that C++ is much more complex and hard to
| write correct code.
|
| That is why in the Windows kernel, according to https://en.wi
| kipedia.org/w/index.php?title=Windows_NT&oldid=..., C++ is
| rather avoided, and C is preferred for kernel code (for user-
| mode code, the priorities are reversed):
|
| "Windows NT is written in C and C++, with a very small amount
| written in assembly language. C is mostly used for the kernel
| code while C++ is mostly used for user-mode code. Assembly
| language is avoided where possible because it would impede
| portability."
| pjmlp wrote:
| Someone has to update that entry,
|
| C++ supported in the kernel since Vista,
|
| https://learn.microsoft.com/en-
| us/cpp/build/reference/kernel...
|
| "The new wil library for C++ code in drivers"
|
| https://community.osr.com/discussion/291326/the-new-wil-
| libr...
|
| > wil was primarily developed by the Windows shell team for
| writing usermode code, but the NDIS and Bluetooth teams
| have contributed some small kernel-specific features.
| Here's a few examples of how you can use wil in your kernel
| driver:
| tialaramex wrote:
| "Hard to learn" ? Google found that when they trained engineers
| to write Rust the majority of engineers reported they were
| confident writing Rust in 2 months or less and a third reported
| they felt not merely confident but _as productive_ as in other
| languages in that time. Google describes this as "in line"
| with numbers for other languages they've taught their engineers
| so apparently it's not especially "Hard to learn" compared to
| other languages used at Google.
|
| https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti...
| steveklabnik wrote:
| > If rust is complex and hard to learn
|
| The problem with this assertion is that it says a _lot_ of
| different things, some of which I 'd believe to be true, and
| some of which I do not.
|
| > Shouldn't readability/ understandability be a critical
| requirement for kernel code?
|
| I don't think anyone is going to say "readability is not
| important," but the problem is that there's a looming question
| of "for whom"?
|
| This is basically part of the issue here. You are making an
| incredibly broad generalization about a fairly complicated
| topic, one of which we don't even have a lot of evidence about,
| but many opinions.
| Aleklart wrote:
| [dead]
| CodeCompost wrote:
| In the Windows GDI library no less, a source of many issues in
| the past.
| bonzini wrote:
| That's not a coincidence...
| jug wrote:
| Interesting Redstone build. That's like Windows trunk, right? I
| wonder if the slew of unusually many and interesting updates is
| due to it eventually going to become Windows 12? They already
| have builds from that branch though (Gallium) although none as
| Insider Preview yet, so I'm unsure how it relates to these.
___________________________________________________________________
(page generated 2023-07-12 23:01 UTC)