ChanServ changed the topic of #kisslinux to: Unnofficial KISS Linux community channel | https://kisscommunity.org | post logs or else | "An idiot admires complexity, a genius admires simplicity." -- Terry A. Davis
<ryoshu> illiliti: I was told that we want a daemon for monitoring
<ryoshu> as we don't want to allow multiple queues, unprivileged that make wired memory
<ryoshu> with a daemon we get normal memory management for messages
<ryoshu> distributed to users
<illiliti> what's the problem with multiple queues? fyi, linux allows unprivileged users to monitor events via netlink without any daemons. why netbsd can't simply allow to do the same thing?
<ryoshu> user-space buffering instead of kernel-space, but it is for consideration
<ryoshu> no problem with setting a limit on the number of users from user-land
<ryoshu> illiliti: regarding subsystem, we have devclass https://nxr.netbsd.org/xref/src/sys/sys/device.h
<ryoshu> we can pass it to userland
<ryoshu> and then we can add a subclass, for certain types of devices, like discrimination of input ones
<illiliti> interesting
<ryoshu> I think this makes all we really need
<ryoshu> https://susepaste.org/de3213bd my internal API
<ryoshu> subsystem->devclass, add devsubclass
<illiliti> looks good
<illiliti> what is *driver?
<ryoshu> kernel driver
<ryoshu> it is returned by drvctl so it would be a waste to drop it
<illiliti> ok
<illiliti> btw, openbsd has similar struct https://github.com/openbsd/src/blob/master/sys/sys/device.h#L53
<ryoshu> it should be a BSD thing
<ryoshu> I abandoned the idea to cache the state of devices in userland; it's prone to races and hard to lock it reliably I decided to always probe the data from the kernel behind the API calls.
<illiliti> yeah, this is good decision
<illiliti> caching is complicated
acheam has quit [Quit: connection reset by purr]
acheam has joined #kisslinux
<illiliti> do you think it would be better to port devd or implement monitoing stuff to devpubd?
<ryoshu> now, I need to decide whether 1) the public api is devicetree.h, write libudev in pkgsrc for poor man compat 2) keep devicetree.h as internal api and export a netbsd specific udev.h that is sufficiently compatible with linux 3) do (2) + optionally add libudev compat harder versions for mimicking hwdb, /sys and netlink/socket
<ryoshu> I would like to switch all users of drvctl(4), including devpubd to devicetree(3)/udev(3)
<ryoshu> devd is freebsd specific, no plans to port it
<illiliti> sysfs, netlink and hwdb is unneeded
<ryoshu> but would a linux-style/like <udev.h> be superior over <devicetree.h>?
<ryoshu> going netbsd-only way is hard and prone to rejects in upstream for patches
<ryoshu> if you can/want to write a version for other kernels, it might be easier
<ryoshu> I don't know your future API plans
<testuser[m]> Hi
<ryoshu> I will try with option (2)
<illiliti> i'll publish the lib soon. i already implemented basic stuff for linux, netbsd and libudev backends
<illiliti> ryoshu: btw, why devicetree if we have drvctl? devicetree depends on daemon?
<ryoshu> I just wanted to pick an internal name, no dependencies on a daemon
<ryoshu> I think it's good to avoid a name libudev, for more proper compat lib; so no libudev linking with libudev
<ryoshu> for the same reason I want to pick <udev.h> instead of <libudev.h>
<illiliti> for consistency sake?
<ryoshu> libdevicetree offering udev.h, on top of that libudev-netbsd and offering libudev.h for emulating /sys and others
<ryoshu> for easier porting
<ryoshu> this is my idea
<ryoshu> dragonflybsd picked name devattr or such
<ryoshu> libdevattr
<illiliti> i don't like this idea. it's confusing
<ryoshu> do you prefer to see the lib named libudev?
<illiliti> my idea: libdevicetree offers devicetree.h and libudev-netbsd offers libudev.h. libudev-netbsd uses devicetree.h underhood
<illiliti> libdevicetree offering udev.h is just confusing
<ryoshu> do you think this API https://susepaste.org/de3213bd is good enough to use in 3rd party software?
<ryoshu> like libinput
<illiliti> you need to provide device type
<illiliti> keyboard, mouse, ...
<ryoshu> yes, this is in progress (devclass + devsubclass)
<illiliti> also, people usually prefer fd for polling instead of function
<ryoshu> and use poll(2) or similar?
<illiliti> yeah
<illiliti> fd is useful because you can embed it into event loop
<ryoshu> I will change that. Looking at libinput source code, it's all clobbered with evdev+udev together
<illiliti> yeah, the code is unreadable mess just like systemd source
<ryoshu> and evdev api uses /sys-related calls
<illiliti> i'll purge them when lib will be ready to use
<illiliti> for now, see how libudev-devd implemented this
<illiliti> what does devicetree_init() do btw?
<illiliti> it uses globals underhood?
omanom6 has joined #kisslinux
ryoshu_ has joined #kisslinux
xy has joined #kisslinux
jslick00 has joined #kisslinux
sammifam1ish has joined #kisslinux
smartin has joined #kisslinux
jslick0 has quit [*.net *.split]
icy has quit [*.net *.split]
omanom has quit [*.net *.split]
barpthewire has quit [*.net *.split]
ryoshu has quit [*.net *.split]
jedavies has quit [*.net *.split]
sammifammish has quit [*.net *.split]
omanom6 is now known as omanom
barpthewire_ has joined #kisslinux
jedavies has joined #kisslinux
jedavies_ has joined #kisslinux
jedavies has quit [Ping timeout: 252 seconds]
GalaxyNova has joined #kisslinux
<GalaxyNova> Hey!
<testuser[m]> hi
<GalaxyNova> I wonder why plan9 didn't catch on like unix did
<GalaxyNova> like
<GalaxyNova> 20 years after unix was released there were already 20 unix-like operating systems
<GalaxyNova> but now we don't see any love for plan9 :(
bountyht has quit [Ping timeout: 252 seconds]
user___ has joined #kisslinux
phoebos has quit [Ping timeout: 252 seconds]
phoebos has joined #kisslinux
lanodan has quit [Ping timeout: 252 seconds]
lanodan has joined #kisslinux
f1_ has joined #kisslinux
f1 has quit [Ping timeout: 252 seconds]
f1_ is now known as f1
GalaxyNova has quit [Quit: GalaxyNova]
konimex1 has joined #kisslinux
konimex has quit [Ping timeout: 250 seconds]
barpthewire_ has quit [Ping timeout: 250 seconds]
barpthewire has joined #kisslinux
user___ is now known as bountyht
<aosync> there is love for plan 9
<aosync> join #cat-v to see it
<aosync> also people in the unix world are more and more aware of what is plan 9 and 9front is more active than ever
<aosync> Plan 9 has been relicensed with MIT earlier this year
illiliti has quit [Quit: leaving]
noocsharp has quit [Ping timeout: 252 seconds]
user___ has joined #kisslinux
bountyht has quit [Ping timeout: 252 seconds]
phoebos_ has joined #kisslinux
phoebos has quit [Ping timeout: 252 seconds]
xy is now known as icy
Uks3 has joined #kisslinux
Uks2 has quit [Ping timeout: 246 seconds]
raph_ael has quit [Quit: WeeChat 3.1]
raph_ael has joined #kisslinux
mahmutov has joined #kisslinux
progenyx has quit [Quit: progenyx]
phoebos has joined #kisslinux
phoebos has quit [Client Quit]
phoebos_ has quit [Quit: connection reset by purr]
phoebos has joined #kisslinux
noocsharp has joined #kisslinux
soliwilos has quit [Ping timeout: 276 seconds]
micro_O has joined #kisslinux
mobinmob has joined #kisslinux
Uks3 has quit [Ping timeout: 252 seconds]
Uks2 has joined #kisslinux
progenyx has joined #kisslinux
<vulpine> is there a port of birch for plan9?
xaf has joined #kisslinux
<testuser[m]> You mean a port of bash
riteo has joined #kisslinux
<riteo> hiiii!
<testuser[m]> hiiiiiiiiiiiiiiiiiiiiii
gtms has joined #kisslinux
jess has quit [Quit: Lost terminal]
<aosync> birch is an irc client made in bash
akira01 has joined #kisslinux
<akira01> hey guys
<akira01> anyone get this in kernel 5.14.9?
jess has joined #kisslinux
<riteo> I mean, as long as those are warning
<riteo> s/warning/warnings/
<cotangent> <riteo> I mean, as long as those are warnings
<riteo> i don't think it matters that much, I guess they'll fix it up upstream eventually
<akira01> Yeah maybe
<riteo> do you guys know any alternative to flowgorithm? The closest thing I found is raptor (it also should run programs afaict) but it's windows only (sort of) and at least it should require me mono
<riteo> the issue with most diagram builders is that they can't "run" the code they represent, I can't find anything more than RAPTOR that does that
<riteo> you know what, I don't need to actually run them, you know, school stuff. There's literally only flowgorithm and RAPTOR afaict and they're both pretty much only for windows.
<riteo> s/I don't need/I don't think I need/
<cotangent> <riteo> you know what, I don't think I need to actually run them, you know, school stuff. There's literally only flowgorithm and RAPTOR afaict and they're both pretty much only for windows.
<riteo> yeah nvm, sorry
<tleydxdy[m]> if you school ask for it, probably better to just use that. perhaps on a school computer
soliwilos has joined #kisslinux
<tleydxdy[m]> tbh I never really find those things intuitive or helpful
<riteo> they were actually pretty chill with the fact that I use a unix-like OS
<akira01> the problem with kiss is missing packages
<riteo> they said that alternatives were fine, so thinking about it I don't think they'll really care that I can't run them
<tleydxdy[m]> yeah, perhaps some sort of visual debugger?
<riteo> akira01: nah, that isn't a big issue imo, I can package everything I need
<tleydxdy[m]> so you can write the code and have flowchart generated
<tleydxdy[m]> rather than the other way around
<riteo> that would be interesting, but would be weird to explain to my teachers lmao
<akira01> riteo: i mean yeah you can do a normal setup
<riteo> idk, I'll talk with them ig
<akira01> but is missing some packages for a develop setup
<riteo> oh wait I thought you meant installing windows, sorry
<riteo> i get what you mean, but IMO the real big missing thing is java, for which I have plans myself (although I wish dylan implemented custom download hooks)
<akira01> yeah java is a big thing
<riteo> but other than that it isn't really *that* unbearable
<akira01> we can port java, alpine and void did this
<riteo> yeah, the biggest issue rn is that kiss is download-first
<akira01> yeah
<riteo> imo custom download hooks should fix this issue, but dylan still hasn't implemented it, altough he teased this feature
<riteo> maybe he forgot or he's just naturally busier since summer ended idk
<akira01> i think he is busier
<akira01> i emailed in some past days
<akira01> but no response
<riteo> oh give it time
<riteo> he replied to me in a week or so
<akira01> is hard to port gimp when glib is missing a feature that he just drop with rm
<riteo> nothing stops you to readd it
<riteo> just fork the package
<akira01> yeah is simple that
<akira01> but i mean
<akira01> how can i port this without this big problem?
<riteo> ehhh, I'm pretty sure that gimp falls into the heavier side of software, I'm not even sure they'd accept it in community
<riteo> so I don't think it's that big of a problem, it's just... Relative?
micro_O has quit [Ping timeout: 252 seconds]
<akira01> maybe will not accept but if i made a repo
<akira01> will need to rebuild glib
<akira01> and this is a shit
<riteo> wait, what feature did he drop exactly?
<akira01> one sec
<akira01> sorry
<riteo> no worries, take your time
<akira01> here
<akira01> actually is gtk+3
<riteo> wait, that isn't glib
<akira01> line 85
<riteo> oh now I get what you mean
<akira01> yeah lol
<riteo> no wait, I've still not clicked the link
<riteo> I referred to the sorry
<akira01> i get little confused
<akira01> but yeah
<akira01> is gtk3
<riteo> oh now I read that line
<riteo> > It has no use at all.
<riteo> lmao
<akira01> missing gtk-encode
<akira01> yeah is just bullshit thing
<riteo> who knows, maybe it's an old thing
<akira01> but gimp need this for build
<akira01> gosh
<akira01> i mean the upstream need this
<akira01> not tested with stable
<riteo> well that line is more than a year old
<riteo> it might easily get removed if it gives actual problems, kiss changed *a lot*
<akira01> is this a little problem in kiss
<akira01> is not well universal packages
<akira01> and if dylan says no, we need to rebuild the package
<akira01> lol
<riteo> nah, it's complicated
<riteo> again, gimp/gtk+3 is on the heavier side, let's remember that fribidi has been purged from the main packages
micro_O has joined #kisslinux
<riteo> it's not an absolute thing, stuff changes while trying to balance simplicity and praticality
<riteo> we're already on the simpler and less pratical side than usual, that's prone to happening
<riteo> s/happening/happen/
<cotangent> <riteo> we're already on the simpler and less pratical side than usual, that's prone to happen
<akira01> i get
<akira01> but later or not kiss will need to port the bloat thing
<riteo> well the point is not to do that
<riteo> just to have a simple base (hell, even just core) which to extend freely
<riteo> you can, and if you need *should*, port bloat, just not in the main repos
<riteo> maybe not even community, to avoid the eudev thing
<riteo> anyways I gtg rn, cya later!
riteo has quit [Quit: epic bloat moment]
Uks3 has joined #kisslinux
Uks2 has quit [Ping timeout: 252 seconds]
xaf has quit [Quit: WeeChat 3.3]
an3223_ has quit [Ping timeout: 276 seconds]
an3223_ has joined #kisslinux
riteo has joined #kisslinux
<riteo> hii! I'm back!
<ryoshu_> hi
gtms has quit [Remote host closed the connection]
<aosync> hi
mobinmob has quit [Quit: Connection closed for inactivity]
smartin has quit [Quit: smartin]
kawics11 has joined #kisslinux
<riteo> welp, I'm messing up with my laptop for now, cya later!
riteo has quit [Quit: epic random reboots time]
barpthewire has quit [Remote host closed the connection]
kawics11 has quit [Ping timeout: 252 seconds]
ryoshu_ is now known as ryoshu
illiliti has joined #kisslinux
ryoshu has quit [Changing host]
ryoshu has joined #kisslinux
<ryoshu> hi illiliti
<illiliti> hi
<ryoshu> _init() initializes globals
<illiliti> hmm
<illiliti> not sure if it's suitable for libraries
<ryoshu> I was thinking about it and I prefer to have one thread reading drvctl(4)
<ryoshu> and distribute events to N readers
<ryoshu> OK. I'm going to try to finish something usable this weekend.
<illiliti> i still think it's better to "fix"/expand drvctl instead of introducing new lib
<ryoshu> and use ioctl(4) directly?
<illiliti> yes
<ryoshu> I am trying to merely wrap it
<ryoshu> direct drvctl(4) has a shortcoming that it relies on kernel ABI
<ryoshu> and API
<ryoshu> e.g. libprop changed
<ryoshu> between netbsd 9.0 and HEAD
<ryoshu> so 3rd party software can use stable API lib
GalaxyNova has joined #kisslinux
<illiliti> you mean drvctl is unstable?
<ryoshu> it uses libprop to send/handle messages, this library changed a little
<ryoshu> example, changes were subtle but libprop is not ideal for pushing to 3rd party software IMO
<ryoshu> I think that handling drvctl(4) is a repetitive code, so nice to wrap it.
<illiliti> ok, valid points. although i don't like wrappers, it seems reasonable here
<ryoshu> one developer planned to replace libprop entirely with an approach based on protocol buffers from google
<illiliti> interesting