I want to learn how printing works in UEFI but can't find any reliable resource that details the function. I don't want to copy from the library as that won't tell me much of how it actually works.
Can anyone please explain how printing in UEFI works?
Thank you
well, this is impossible, because the printing behavior does not print anywhere really, you can see it on UEFI Shell which is an UEFI App by itself.
If you want to implement low level printing, you can read about using serial ports, this is the easiest one.
Related
I'm looking for a way to use native Racket methods of getting some statistics about the host machine the application is running on like free disk space, memory use and processor use. So far I haven't found a library that reports this information within Racket; is there an idiomatic method to get this information or is the only way to find external executables and parse the results on each platform the application runs on?
I'm confident that you're not going to find this functionality in a library that's bundled with Racket. On the other hand, I see no reason why this couldn't be implemented as a Racket library that does not use an external executable. I'm not saying that it is, only that it almost certainly can be implemented as a library. Does that answer your question?
I want to read out and log my iMacs power consumption. Anybody has an idea how I can do that.
Swift, Shell or Ruby would be great!
Thanks a lot,
André
It sounds like you're talking about a non-laptop that doesn't use a battery, so there isn't nearly as much useful power usage information available as you might be able to get for a laptop that does use a battery.
But either way, if this were my problem I'd start writing a Swift app or a command line tool that incorporates the IOKit framework, which has a few header files with useful information, such as IOPowerSources.h and IOPSKeys.h.
More detail can be seen in the "Hardware Access Options" section of this Apple documentation.
I need a simple example like an echo server as a FreeBSD kernel module (or syscall).
I have seen OpenKETA, but it has a large code, it's too difficult to understand and use it.
Is there a simple example?
Not sure what you're trying to accomplish, and not to advertise, but based on the question, I'd suggest getting a copy of Designing BSD Rootkits and FreeBSD Device Drivers. I've read both and I think they will help you.
You probably want to take a look at documentation for sosend(9) family of functions (man 9 sosend). Those are the kernel routines to operate on sockets.
I am contemplating writing a daemon programme for FreeBSD, however, I've never done it, and by the looks of it, it's quite tricky.
Are there any libraries that I could include and then just write the things specific for my daemon?
Sorry for posting this an answer rather than a comment - I don't have enough reputation to do the latter.
You might want to look at daemon(3), a function provided in FreeBSD's libc. It does things like close the standard file descriptors, set things up so SIGHUP will have no effect, and so on. The source code is here:
http://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?view=markup
There's also a man page. (Be careful, there's also a wrapper program, daemon(1)). Also note that it's not portable (though it may be available in libbsd, I'm not sure).
FreeBSD also provides libutil (again, not portable I think), which among other things provides pidfile_*() functions for handling PID files, which I suppose is useful for writing a daemon. There are other considerations, but this might help you get started. Can't say much more unless you have a specific question.
I've written some Perl programs and am planning on distributing them. They're part of a large binary distribution (mostly compiled C/C++). If possible, I'd prefer to give up as little as possible (I'm responsible for delivering working software, not delivering clever algorithms). What is my best bet for hiding the Perl code so that if someone really wants to see the source, they'd have to put a bit more effort than in than simply opening the file in an editor?
You could encrypt your code and then at run time decrypt it and send it to perl stdin. (of course the decryptor would not be encrypted).
I got some minify/compile answers to my question How can I compile my Perl script so to reduce startup time?
Acme::Bleach
Filter::Crypto (potentially via PAR::Filter::Crypto) is clearly the most advanced open source tool for this job (barring perlcc which doesn't work well for many things, YMMV).
If all you want is hide the code from casual tinkerers, that's more than sufficient. Hiding it from determined and/or capable people is practically impossible.
It won't make it harder to just open the files but an obfuscator can make it more difficult to understand and modify your code. Have a look here or here for a start.