On Mon, Jan 19, 2015 at 08:56:10PM -0500, Jude Nelson wrote:
Regarding the architecture, I have a design document here:
http://judecnelson.blogspot.com/2015/01/introducing-vdev.html Is this what
you're looking for? Or did you want a more low-level document describing
the implementation
Hi Isaac,
Excellent point about vdev_linux_sysfs_read_device_mode(). For the very
reason you mentioned, that code is on the way out. It was (incorrectly)
used in a couple other places in the past before I knew better, but right
now it's only use is in confirming that a device that has a known
Gravis said:
the first release will be almost the same as debian with the
exception of packages needing systemd. after that i dont
know but we would need hardware to test on to make any
direct changes.
Hi Gravis. Yes, that's kind of what I figured. I'll do a little more
exploring on the
# [Devuan Weekly News][1] Issue VIII
__Volume 02, Week 3, Devuan Week 8__ https://git.devuan.org/Envite/devuan-
weekly-news/wikis/past-issues/volume-02/issue-008
## Editorial
Welcome to Devuan Weekly News issue VIII. After two months has passed
from the start of the project (or better, from
Steve Litt said:
I've heard anecdotes of the UEFI system writing to persistant memory on
the motherboard in a way that an app misusing UEFI could brick the
motherboard. Therefore, the only time I use UEFI is when I absolutely
must have Windows on the laptop, and the Windows that came on the
On Mon, Jan 19, 2015 at 04:05:46PM -0500, Jude Nelson wrote:
Hey Isaac, this looks great! Starred and watched :)
Thanks!
Related, I've just committed some (very) preliminary code for
libudev-compat in the vdev repository that's meant to be both API and
ABI-compatible with libudev. I think
Hi Isaac,
I was asking about implementation details (something like the HACKING
document that many projects have, giving an overview of how it works
internally).
Good idea; I'll add one.
I'm getting the impression that libsysdev won't really make a good
backend for the udev API; libudev is
the first release will be almost the same as debian with the exception
of packages needing systemd. after that i dont know but we would need
hardware to test on to make any direct changes.
On Mon, Jan 19, 2015 at 9:36 AM, Robert Storey robert.sto...@gmail.com wrote:
Hello everyone. This is my
On Mon, 19 Jan 2015 22:36:42 +0800
Robert Storey robert.sto...@gmail.com wrote:
I encountered an issue which hasn't been discussed here yet: support
for UEFI boot (as opposed to BIOS) and a hard disk partitioned as GPT
(as opposed to MBR).
[snip]
Anyway, today I decided that it was about
Hello everyone. This is my first post, though I've been lurking on the
mailing list for awhile. Until now I've been content to shut up and let
more knowledgeable folks discuss the technical details, but today I
encountered an issue which hasn't been discussed here yet: support for UEFI
boot (as
On Sun, Jan 18, 2015 at 01:11:15PM +0100, k...@aspodata.se wrote:
Isaac Dunham:
On Sat, Jan 17, 2015 at 08:06:05PM +0100, k...@aspodata.se wrote:
Also a lib that maps major/minor to /dev/name and the like, a command
that scans lspci and the like, and suggests kernel modules,
which I
Hey Isaac, this looks great! Starred and watched :)
Related, I've just committed some (very) preliminary code for
libudev-compat in the vdev repository that's meant to be both API and
ABI-compatible with libudev. I think we're working towards the same
end--make a library that can replace
On Mon, Jan 19, 2015 at 10:21:56AM -0500, Gravis wrote:
after that i dont know but we would need hardware to test on to make any
direct changes.
While for comprehensive testing you need an array of real hardware (as
quirks vary wildly), for basic tests you can use VMs:
* virtualbox: just click
On Mon, Jan 19, 2015 at 11:01:16AM -0800, Isaac Dunham wrote:
I'd like to provide something that can be utilized as a fallback when
libudev is missing/udev doesn't start.
Optimally, the API will be simple enough that developers then say
And why aren't we using this *instead* of libudev?
14 matches
Mail list logo
