Re: Kernel Improvements

Re: Kernel Improvements

[Michael]

[-- Attachment #1.1: Type: text/plain, Size: 1432 bytes --]

The philosophy "everything is a file" is a cornerstone of UNIX and Linux
design, offering a unified interface for interacting with resources, be
they hardware or software. Shifting to a paradigm where "everything is a
database entry" or "active record" introduces a layer of abstraction that
could compromise the simplicity and directness for which Linux is renowned.

1. **Performance Overhead**: Databases introduce latency and CPU overhead,
affecting system responsiveness.

2. **Complexity**: Managing schemas, indices, and transactions adds
unnecessary complexity for basic operations.

3. **Scalability**: File operations in Linux are optimized for performance
and can scale horizontally. A database model may not offer the same
scalability without significant engineering.

4. **Compatibility**: Existing applications rely on file-based APIs. A
transition would necessitate widespread code changes, breaking backward
compatibility.

5. **Principle of Least Astonishment**: Linux users expect a file-based
paradigm. Changing this could alienate a significant portion of the
community who rely on existing interfaces and behaviors.

6. **Transparency and Control**: Databases are often opaque, whereas the
"everything is a file" design gives developers direct access to resources,
offering more control.

While innovation is vital, it's crucial to weigh these concerns carefully
against the benefits your proposal might bring.

[-- Attachment #1.2: Type: text/html, Size: 1673 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Kernelnewbies Digest, Vol 154, Issue 14

[Michael]

[-- Attachment #1.1: Type: text/plain, Size: 16178 bytes --]

Apologies on my last message, I didn't respond directly to Juro,

Sorry Juro!

On Mon, 25 Sept 2023 at 19:45, <kernelnewbies-request@kernelnewbies.org>
wrote:

> Send Kernelnewbies mailing list submissions to
>         kernelnewbies@kernelnewbies.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> or, via email, send a message with subject or body 'help' to
>         kernelnewbies-request@kernelnewbies.org
>
> You can reach the person managing the list at
>         kernelnewbies-owner@kernelnewbies.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kernelnewbies digest..."
>
>
> Today's Topics:
>
>    1. Kernel improvements. (Juro Dobr?k)
>    2. Re: [Question] dt bindings for BeagleConnect (Krzysztof Kozlowski)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Sep 2023 04:47:17 +0200
> From: Juro Dobr?k <dobrik.juro@gmail.com>
> To: kernelnewbies@kernelnewbies.org, freebsd-accessibility@freebsd.org
> Subject: Kernel improvements.
> Message-ID:
>         <CAAG+mdToFpmG48SC24i9ErMK9JExMMUzRjePwH=
> YEnN0Kqv28g@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> In UNIX, everything is a file. I am here to make that a database. Yes, in
> new system paradigm, everything is database entry, or active record.
>
> Kernel wide database should have defined bytecode of request possibilities,
> along with pointer reference to query data.
>
> At some space in disk, there should be hardcoded in system kernel, that we
> can only write there. It should be proposed to store deep logs.
>
> There should be guy for filtering logs, they should be more of serialized
> entries in database than a line of text. If errors are serialized data, we
> can check public errors repo for possible fix, with some data like new
> keywords provided by user, but fix from database will be applied after
> showing fix and affirmation by the user.
>
> Short range packet history of network also should be on write only space.
> So we can raid out possible intruders and inspect packets. However with
> master permission we could send packet out in invisible format or recieve
> them like that, but it'll require finger prints, an absence of data will be
> also locked.
>
> Now whole system is database, how do we pass data from database to process?
> Simply passing read start and read end and call to refill bucket function.
> We also pass metadata on how to decode such thing.
>
> When it comes to metadata, we live in world of machine learning, therefore
> we can have something like system registry of data, and also software
> packages, for packages, they may come in bundles, install should be
> rollbackable by also setting context of packet when doing something else,
> so like we can rollback install completely, install multiple versions
> alongside itself, each packege should be working standalone or they can
> come in preconfigured bundles. Whole configs along with data should then be
> made installable. We should be able to define system instance that runs
> under supervisor, which is copy on write copy with only data access we
> selected.
>
> That thing can be solved like there's hook for copying for both sides.
>
> There should be manipulable path when writing to filesystem, consisting
> only of compression with LCache fitting dictionary and encryption. Maybe
> compress - encrypt will make it to hardware, with huge memory for
> dictionary and not using only words but also patterns.
>
> Disks should have innovative raid approach, write in parallel and on no
> writing copy to mirror.
>
> Virtual networks, tunnels and firewalls and redirection should be on one
> section of system, with GUI that enables configuration of those properties
> we need and also shows each process that uses network, so we can route
> that. Or we can preconfigure this config on new instance, in that case
> config is fixed with keyword, not the address itself.
>
> With online repository for errors, software, data, models, whole system
> instances, we can also have this repositories peer to peer utilizing
> blockchain consensus algorythm.
>
> System should have be possible configured 8n a way that it only boots with
> key USB Stick.
>
> Storing of sensitive data on the system should be done in encrypted space
> on hardisk that runs on main master instance and you should must give
> permission for other instances to access that sensitive data for system for
> being able to access passwords.
>
> Passwords entered in instance should be possibly better being exported with
> it in sone cases.
>
> And I am talking about all passwords entered in webbrowser and also
> elsewhere, it could even remember archive passwords on permission, also
> passwords should be savable in instance config, but they could be make to
> insert of ow  on beggining of config
>
> Database of passwords can be stored in cloud firstly encrypted by symmetric
> encryption.
>
> Each RAM's kernels specified segment would have rwx settable permissions
> individually for different users and processes.
>
> Passwords should be related to master username, different ussers could have
> different password for each service.
>
> Did already said that databasea can be passed in Kernell by passing
> reference to write start, end and refill bucket function? Along
> withmetadata of course.
>
> Filesystem operations(cp, mv, rm) could have main proccess that kewps track
> of them, and lets you browse and rollback those.
>
> Option to make driver instance(the main os) just from hardware already
> plugged in, not keeping unnecessary drivers in living memory, while
> installing instances of os drivers doesn't play role.
>
> Always rewrite memory with pattern when allocating it to some process.
>
> Let the kernel be king of which sort algorythm to use and therefore we
> should make sort an kernel operation, we pass metadata and data to kernel,
> and also write head which writes or 3xecutes sorted data.
>
> Application for deconstructing XWindow or Wayland, also properly sorting
> there. But any window should be blurable or even have different computed
> layer on what's under that.
>
> Window snapping. With normalenviroments like plasma, we should also have i3
> like keyboard shortcuts to do operation on windows.
>
> Also we could hardly benefit from having guy, in which we can with keyboard
> controll explore system.
>
> Live editor of memory on system, ability to stop a process in middle of
> execution and examine it's memory {from master down we can examine even
> whole kernels}.
>
> Graphic interface for users, groups.
>
> Graphic interface to explore recent network packets.
>
> Special filesystem, that store all text files in database with possible
> undos and redos, and other files are stored normally on disk.
>
> Graphical program that let's us engrave simething into bits of HDD, like a
> picture from it's magnetic potential.
>
> Snapshots of system lower instances, that can be stored on disk and played
> later.
>
> Fingerprint authentification,
> Face recognition that writes log about who sits on computer, like nobody
> without password cannot replace you in computer chair and continue your
> work.
>
> Optimize hashmaps in kernel. Like combination of checksum and skip table is
> good.
>
> Brainstorm even weirdest optimizations over db you've ever heard.
>
> Compilers will have they own package system that'll automatically install
> library for the compilation for header from public repository.
>
> If library haven't got it, it sort by kernel's sorting function, compiler
> adds binary search when applicable, optimizes hashmaps based on benchmarked
> performance in specific application.
>
> Graphic editor of bootloader menu, splash screen documentation, linux
> command tip on loading showed on screen.
>
> File system for images, which use AI to categorize them and sort them.
>
> Best of all 'script' javascript derivative for event driven asynchronous
> operation scripting. With all the system entries of services, possibility
> to change config and reload it. Having ORM system for kernel database.
> Having also good date and time functionality and full power to do API
> calls.
>
> If you are registered at webservice, you can get your own url, which may
> act as webhook for this API service.
>
> Kernel will also have some conditional loops, it's graph, along with whole
> instance would be parsed trought looking for malicious behaviour.
>
> Script should be also capable to control web browser to some extent.
>
> Also gui to browse and change all the data provided to instance, including
> strings, fonts, patterns, barelly anythint.
>
> Online repository for live wallpapers out of generative art.
>
> API SDK repository. Yea, script will have SDK's ready, that's why yoy
> should develop open standards for information transfer and requesting.
> Binnary with metadata about format is best way to go. Open API standards,
> datatype standards and their version.
>
> Possible two factor authentification if computer is connected to internet
> or with bluetooth.
>
> Possible authentification for wheel group by common access card along with
> fingerprint and password.
>
> When reversing array itetation, just replace op code in instruction stack
> with one that does reduce pointer and returns lenght-current as position.
>
> Analyze executed binaries by asynchronoys acyclic graphs with cyclic
> groups, in GUI, to know they are going to do something that shouldn't be
> there. They can be verified once saved checksum, and if no much change in
> checksum, then don't commit whole analysis again. Some points are going to
> be different, but it's whole picture that matters.
>
> Also, have I mentioned, you can have digital well beings apps down from
> this everything is database thing, and with that data you can have like
> automatic selection of music, that gets along with your current situation.
>
> Note-taking app, that support hypertext, keywords, autographing, and
> 'script' and database, would be really useful too.
>
> And you could pick, which or what kind of data you will sync to your phone.
>
> And when it comes to your phone, it can have pre-fetched content for
> offline browsing.
>
> And you can sync it with bluetooth/wifi/VPN so you can read reports from
> computer on the way to work.
>
> Also audiofiles should be database, vectorized for simillarity search,
> stored on specific file system, along with metadata, and if they are fresh
> maybe they are still seedbacking to community trought peer to peer sharing.
> Preffered format:FLAC with cache size of dictionary, prefferably big common
> dictionary, and then separate derivatives of compresion core.
>
> Part of hard disk non encrypted bootable system, that boots only to ram and
> have very restricted functionallity.
>
> Also for 16GB RAM swap with hibernate you need 32GB's of RAM.
>
> Filesystem with rollbacks possible. Even rollback with persist something is
> programatically possible.
>
> Kernel wide memento for undo button that carries inverse of any function
> done, or original of cow's before change on part and undoes even that you
> copy pasted something.
>
> That's All Folks.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20230921/93a01ffd/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sat, 23 Sep 2023 18:08:30 +0200
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> To: Ayush Singh <ayushsingh1325@gmail.com>, devicetree@vger.kernel.org
> Cc: conor+dt@kernel.org, robh+dt@kernel.org,
>         krzysztof.kozlowski+dt@linaro.org, kernelnewbies@kernelnewbies.org
> Subject: Re: [Question] dt bindings for BeagleConnect
> Message-ID: <de6c83ca-ddda-4c74-d9ea-e7c388f60b88@linaro.org>
> Content-Type: text/plain; charset=UTF-8
>
> On 23/09/2023 18:04, Ayush Singh wrote:
> > Hello everyone, I am working on writing a BeagleConnect driver for
> > Beagleplay board. Let me first go over some terminology:
> >
> > BeagleConnect is both a technology concept and a line of board designs
> > that implement the technology. Born from Greybus, a mechanism for
> > dynamically extending a Linux system with embedded peripherals,
> > BeagleConnect adds two key elements: a 6LoWPAN transport and mikroBUS
> > manifests. The 6LoWPAN transport provides for arbitrary connections,
> > including the IEEE802.15.4g long-range wireless transport supported
> > between BeaglePlay and BeagleConnect Freedom (the first BeagleConnect
> > board design). The mikroBUS manifests provide for rapid prototyping and
> > low-node-count production with sensor boards following the mikroBUS
> > freely-licensable embedded bus standard, such that existing Linux
> > drivers can be loaded upon Greybus discovery of the nodes.
> >
> > BeaglePlay consists of a main AM62 processor and a CC1352 co-processor
> > which is responsible for providing 6LoWPAN support along with Greybus
> > node discovery. The AM62 processor and CC1352 are internally connected
> > over UART. The CC1352 coprocessor is supposed to run a specific firmware
> > as a part BeagleConnect setup. It looks as follows:
> >
> > AM62 (Linux Driver) <--UART--> CC1352 (Zephyr Firmware) <--6LoWPAN-->
> > BeagleConnect Freedom
> >
> > I need a way to access this bridge UART. The most straightforward method
> > is adding a `compatible` property to the device tree of this UART. But I
> > am not sure how to go about adding a DT binding for it that can be
> > merged upstream.
> >
> > Here are a few comments I have encountered:
> >
> > 1. DT bindings need to be hardware
> >
> > I am not sure which hardware the bindings need to target in my case.
> > Should the bindings be serial in nature, since I need to use the UART
> > device? Or they should be about SoC since CC1352 is the device I am
> > actually communicating with? Or maybe there is a 3rd category for an SoC
> > running a specialized firmware for a technology/protocol?
> >
> > 2. DON'T create nodes just for the sake of instantiating drivers.
> >
> > I guess this means that adding a child node just to add a `compatible`
> > property is not allowed? For some reason, the driver probe is not called
> > if I simply try to override the top level `compatible` property of the
> > serial device. But maybe that is just an issue with my approach?
> >
> > 3. DO attempt to make bindings complete even if a driver doesn't support
> > some features.
> >
> > This is only relevant if the answer to 1) is the SoC. Since the CC1352
> > device cannot be directly controlled by, the capability of this device
> > is defined by the firmware running on top of it rather than the
> > hardware. So I am not quite sure what a complete binding for such a
> > device even mean. The only property I can make required would be the
> > `compatible` property and everything else will be optional I guess?
>
> Referring to some comments without the context - patch and the comments
> given - makes any discussion difficult. We do not work like this in
> upstream communities. Please respond inline, not top posting, to the
> comments you received.
>
>
> > I understand that strict guidelines are required since once a property
> > is added to the Kernel device tree, it will almost be impossible to
> > remove without breaking compatibility. So I would like some guidance or
> > maybe some similar devices that are already a part of the kernel which I
> > can look to for guidance.
>
> There are plenty of other serial-attached MCUs. Just look for "mcu {"
> (for serial) or mcu@ (for other buses).
>
> Best regards,
> Krzysztof
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
> ------------------------------
>
> End of Kernelnewbies Digest, Vol 154, Issue 14
> **********************************************
>

[-- Attachment #1.2: Type: text/html, Size: 19761 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies