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