Announcement

Collapse
No announcement yet.

The Latest Progress On Rust For The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ssokolow
    replied
    Originally posted by cl333r View Post

    Saying it doesn't make it so. The borrow checker is at the core of Rust development, it's Rust way to enforce the borrowing rules at compile and runtime.
    borrow semantics are at the core of Rust development. The borrow checker, which is a compiler pass, is just the means by which they're enforced 99% of the time. Thus why people tend to conflate them.

    Leave a comment:


  • cl333r
    replied
    Originally posted by jacob View Post

    Just drop it. You have proven to be a clueless moron who knows nothing about Rust, concurrency or software safety and you are full of shit on each of these topics. mdedetrich was mistaken about RefCell but s/he is not hell bent on crass ignorance combined with unwarranted condescension. Unlike you.
    It works both ways my little funky piglet, so just drop it. You have proven to be a clueless moron who knows nothing about Rust, concurrency or software safety and you are full of shit on each of these topics. mdedetrich was mistaken about RefCell but s/he is not hell bent on crass ignorance combined with unwarranted condescension. Unlike you.

    Leave a comment:


  • cl333r
    replied
    Originally posted by jacob View Post

    Saying it doesn't make it so. The borrow checker is what the Rust developers say it is, what the compiler source code says it is and what the Rust community says it is. You could decide to call the libc the "C preprocessor" or you could decide to call New York "Paris", it wouldn't be the case. But at least you have successfully recognised the word "borrow" and jumped to a wrong conclusion, congratulations. That's still more intelligence than you've otherwise shown in this discussion.
    Saying it doesn't make it so. The borrow checker is at the core of Rust development, it's Rust way to enforce the borrowing rules at compile and runtime.

    Leave a comment:


  • oleid
    replied
    Originally posted by oiaohm View Post

    That is not the define of the rust Language. The source code of the compiler is not a language define. Rust borrow checker is define in the rust language documentation and does include RefCell.
    Wrong, rust is defined by its RFC process and the RFC repository. And certainly for parts which don't have an RFC by the source code.
    Some of the links presented in this thread link to the "official book". That is written by third party and was donated to the community.
    Last edited by oleid; 14 September 2021, 03:45 AM.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by oiaohm View Post

    That is not the define of the rust Language. The source code of the compiler is not a language define. Rust borrow checker is define in the rust language documentation and does include RefCell. Just because Rustc is a this stage still a incomplete implementation is not reason for stating the language defined bit wrong.
    And the documentation for the compiler said the borrow checker is a compile time phase in the compiler. The documentation for RefCell says that it can satisfy borrow semantics at runtime (along with other things that has nothing to do with a borrow checker, as said previously its also a reference counter)

    Try again

    Originally posted by ultimA View Post

    This more of a theoretical issue than a real one. When an application requests memory from an allocator such as malloc, the allocator will rarely make any requests to the underlying OS, as it requests memory in batches of pages from the OS, and most times the allocator just returns memory from memory areas that it has already reserved a "long" time ago and have been written to. And even if the application is unlucky enough so that its current request just caused a new page reservation from the OS, the allocator will still have written the page for its internal bookkeeping before the app gets the new pointer returned.
    The point is there is a reason why the behavior of panic'ing/crashing when you are no longer able to allocate memory is a default. In practice, time and time again for typical applications/libraries its shown that this is the most reliable thing you can do. There are of course exceptions (such as the kernel itself and programs such as databases) but otherwise you should really crash (just after printing any relevant state, if possible)

    You also need to distinguish between exceptions and business logic errors, no one is saying that an app should crash because you put text into a field that is expecting digits as input validation but there is a certain class of errors (such as being unable to allocation memory) where there isn't any reasonable behavior that an application can do.

    Typically when these cases happens its considered a bug and you need to resolve it
    Last edited by mdedetrich; 14 September 2021, 03:47 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by mdedetrich View Post
    No its not, check the source code of the Rustc compiler please, I already linked the actual compiler documentation previously.
    That is not the define of the rust Language. The source code of the compiler is not a language define. Rust borrow checker is define in the rust language documentation and does include RefCell. Just because Rustc is a this stage still a incomplete implementation is not reason for stating the language defined bit wrong.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by ultimA View Post

    This more of a theoretical issue than a real one. When an application requests memory from an allocator such as malloc, the allocator will rarely make any requests to the underlying OS, as it requests memory in batches of pages from the OS, and most times the allocator just returns memory from memory areas that it has already reserved a "long" time ago and have been written to. And even if the application is unlucky enough so that its current request just caused a new page reservation from the OS, the allocator will still have written the page for its internal bookkeeping before the app gets the new pointer returned.
    Not necessarily. Nothing says the allocator needs to store metadata in every page allocated. For example, if you request 50 times the size of a page worth of contiguous memory (eg. to store a chunk of file contents), the allocator probably isn't going to write to every page returned.

    Leave a comment:


  • ultimA
    replied
    Originally posted by ssokolow View Post

    On various platforms (Linux included), you don't really have any choice, because the kernel defaults to overcommit semantics to compensate for applications that waste a ton of memory on Windows by mapping much more memory than they actually write to.

    That means that, even if you're handling malloc failure perfectly well, malloc will return success but, when you try to write to that memory, the kernel may suddenly realize it's overpromised what memory is available and have to kill something after all the branches for handling allocation failure in the software have already been told it was successful.
    This more of a theoretical issue than a real one. When an application requests memory from an allocator such as malloc, the allocator will rarely make any requests to the underlying OS, as it requests memory in batches of pages from the OS, and most times the allocator just returns memory from memory areas that it has already reserved a "long" time ago and have been written to. And even if the application is unlucky enough so that its current request just caused a new page reservation from the OS, the allocator will still have written the page for its internal bookkeeping before the app gets the new pointer returned.
    Last edited by ultimA; 13 September 2021, 03:50 PM.

    Leave a comment:


  • binarybanana
    replied
    How allocation failure is handled is a purely library level thing in Rust, so worst case it can be signaled the same way as in C, but since it's Rust it will look like Option<*mut usize [u8]> (or some "Byte" type instead of u8, perhaps for non-8 bit byte arch support if that is a thing). Constructors might then perhaps return Result<T, AllocFailure> or some such. It's unfortunate that std is lacking here, just like it lacks custom allocator support for collections, but that doesn't affect how this can be handled in the kernel.

    I'm not sure what role overcommit plays in all this, I guess that isn't even really a thing in kernel space? But yes, if you want allocation to ever actually fail you have to do it like Windows and require as least as much RAM+swap as has been allocated, even if it's untouched by the process, which opens up its own can of worms, like programs OOMing even if half your RAM is free. This makes Windows totally unusable without tons of swap. I had CyberPunk 2077 crash on me every other hour until I realized that I needed more swap even though RAM was still far from exhausted, plus the swap file wasn't even being filled, which made the error in the Windows event viewer pretty puzzling, indeed. Until I remembered that Windows doesn't do overcommit... If you absolutely *need* utmost reliability you don't allocation at runtime at all, like safety critical and most embedded systems. I don't really see the point of some awkward middle-ground like on Windows, but I guess some do.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by ultimA View Post
    All I'm saying, the notion of "wanting to crash by default" is actually a very poor choice for any application (user-land or kernel, embedded or desktop) that wants to handle failures itself, and there is plenty of reasons to do so. And I'm also saying this as a full-time developer. Wanting to handle failures yourself is the good coding practice, not blindly crashing. If it turns out you don't have enough memory to even handle the failure gracefully, you'll just crash anyway so you're not any worse than Rust's default, but in all likelihood you'll success by being graceful. Not being graceful and simply crashing might be the better choice if the only alternative is not having any error checks done by the programmer at all, but that is only for poorly written programs, and I'm sure that's not Rust's targeted use-case.
    On various platforms (Linux included), you don't really have any choice, because the kernel defaults to overcommit semantics to compensate for applications that waste a ton of memory on Windows by mapping much more memory than they actually write to.

    That means that, even if you're handling malloc failure perfectly well, malloc will return success but, when you try to write to that memory, the kernel may suddenly realize it's overpromised what memory is available and have to kill something after all the branches for handling allocation failure in the software have already been told it was successful.

    Leave a comment:

Working...
X