[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: (HBI) Implementing SQLite into the FreeBSD kernel
From:       abhja kaanlani <unidef_rogue () live ! com>
Date:       2019-04-30 1:29:11
Message-ID: BL0PR02MB5697C679C1F5CE6887EF6141833A0 () BL0PR02MB5697 ! namprd02 ! prod ! outlook ! com
[Download RAW message or body]

Hi Enji,

I'd just like to start off by saying I'm a very new kernel developer and I appreciate \
everyone's responses

But what would a FreeBSD build be like with sql lite? Wouldn't it kind of be like \
c++? Minus a level of abstraction, but there would BE a level of abstraction. 

There could be a driver that interfaces with other sql databases, and maybe moves \
data to the cloud. 

But just a char *dev_id_description; to some structures could help the kernel be more \
dialectical 

I looked up libnv, I think I can try to hack it to use multiple dimensions, it can be \
easily reimplemented in the kernel! Thanks enji!

Thanks everyone!


Sent from my iPhone

> On Apr 29, 2019, at 5:11 AM, Enji Cooper <yaneurabeya@gmail.com> wrote:
> 
> 
> > On Apr 28, 2019, at 9:20 PM, abhja kaanlani <unidef_rogue@live.com> wrote:
> > 
> > It can be used for messaging. Let's say, for any reason, a userland command needs \
> > to access the sound hardware, there can be a string sql value (or just a string, \
> > kind of like sysctl) attached to a driver, and it can contain metadata for \
> > automation or parsing, maybe even a callback system 
> > and sadly I don't know much of sql. I have a neural database in the works but \
> > that's moving to c++, but a simple binary tree with a couple of character arrays \
> > and an id along with search functions (Libc can handle this fine) can simulate a \
> > small database without consuming too much memory once written to disk 
> > It could be used for up, but there's way too much overhead I think, once I sit \
> > down with my cigarettes and read the entire kernel on my desktop I'll see if I \
> > can add a database like this to some drivers or file system code 
> > 
> > 
> > struct idb_node0 { 
> > int *id;
> > char *idb_node_description;
> > struct idb_node0 *id_node0_direction[MACRO_AND_ENUM_GOES_HERE]  // additional \
> > dimensions if ram calculation allows, I'd suggest some kind of matrice };
> > 
> > struct idb_binary_tree { 
> > int id;
> > char *idb_binary_tree_description;
> > struct node0 *idb_binary_tree_direction[MACRO_ENUM];
> > }
> > 
> > Etc sorry I didn't have time to write the macros and enumerations
> > 
> > Macros and enumerations are used to keep how many items in an array, what \
> > dimension should the array have if ram permissible, and keep track of nodes and \
> > indices 
> > 
> > What I'm getting at is a hardcoded database has its benefits!
> 
> Hi Abhja,
> 
> SQLite in the kernel seems a wrong option for dealing with key-value stores.
> 
> Are you aware of libnv in FreeBSD (and its kernel analog)? It's a key-value store \
> library/infrastructure, available for kernel use. 
> FreeBSD also has access to radix tries too, if the structure matters.
> 
> Hope this helps,
> -Enji
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


[prev in list] [next in list] [prev in thread] [next in thread]