Opening and wriiting to file in Kern
Does anyone know the correct calls to open a file, write to it, and close it, IN *kernel* mode. Ash ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opening and wriiting to file in Kern
Ashwin Chandra wrote: Does anyone know the correct calls to open a file, write to it, and close it, IN *kernel* mode. Ash There is no common API for doing this, which is pretty much on purpose. First, you need to ask yourself why your task needs it done in the kernel and not in userland. If you mist do this, the general set of steps are: 1. use namei() to convert a pathname to a vnode 2. Use vn_open(), vn_rdwr(), and vn_close() to operate on the vnode. 3. Observe proper vnode locking and reference counting with vref(), vn_lock(), and vput() Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opening and wriiting to file in Kern
--- Scott Long [EMAIL PROTECTED] wrote: Ashwin Chandra wrote: Does anyone know the correct calls to open a file, write to it, and close it, IN *kernel* mode. Ash There is no common API for doing this, which is pretty much on purpose. First, you need to ask yourself why your task needs it done in the kernel and not in userland. A feature implemented within the kernel that requires making stuff persistent would almost certainly require file I/O. For that matter, a kernel (module) that reads a configuration file will also need the same facility. I don't see anything wrong with providing a stream (like) interface to the filesystem. regards -kamal __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opening and wriiting to file in Kern
On Sun, Feb 06, 2005 at 04:22:41AM -0800, Kamal R. Prasad wrote: --- Scott Long [EMAIL PROTECTED] wrote: Ashwin Chandra wrote: Does anyone know the correct calls to open a file, write to it, and close it, IN *kernel* mode. Ash There is no common API for doing this, which is pretty much on purpose. First, you need to ask yourself why your task needs it done in the kernel and not in userland. A feature implemented within the kernel that requires making stuff persistent would almost certainly require file I/O. For that matter, a kernel (module) that reads a configuration file will also need the same facility. I don't see anything wrong with providing a stream (like) interface to the filesystem. While there might indeed be nothing wrong with it, besides added complexity, the traditional way to do it would be to have a userland configuration utility that communicates with the kernel module either via ioctl's on some standard device, or via ioctl's or reading/writing of a driver-specific device. This has the advantage of being a bit more portable - while different OS's implement disk/file I/O within the kernel in wildly different ways, all OS's provide relatively simple ways for a kernel module to define a new device and handle ioctl's to it, and all OS's provide basically the same userland-to-kernel interface for having a program open a device and issue ioctl's to it :) Another way would be, again, communication between a userland utility and a kernel module, but this time using mmap'd files/devices instead of ioctl's. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. pgpIe37hBohxn.pgp Description: PGP signature
Re: falloc()
On Sat, 5 Feb 2005, Yan Yu wrote: I am wondering if there is a way to use kernel loadable module to replace the original falloc() (kern/kern_descrip.c) in the system. I know how to do this if the funciton to be replaced is some system call function or ufs* operatio ( i could just change the symbol table which holds these function pointers),. but i could not find the symbol table which holds the falloc() function pointer... falloc() isn't considered a pluggable kernel API, that is to say, we've not engineered FreeBSD with the intent that it be replaced at run-time. As such, to get falloc() replaced on your out-of-the-box FreeBSD install, you'll need to modify the kernel linking. falloc is non-static, so it should be an exported symbol from kern_descrip.o and in theory exposed to modules -- however, replugging the current reference in kern_descript.o might be the hard one to modify. If you don't mind my asking, what motivates you to replace falloc()? Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opening and wriiting to file in Kern
On Sun, 6 Feb 2005, Ashwin Chandra wrote: Does anyone know the correct calls to open a file, write to it, and close it, IN *kernel* mode. I fyou want to be file system independent, you can currently do it using two different currently available kernel abstractions: - VFS interface. Using vn_open(), return a reference to an opened vnode. Use vn_rdwr() to perform I/O on the vnode, and vn_close() to close it. Make sure to properly lock the vnode during I/O and other operations. This interface is abstract in the sense that it's file systme independent, but not in most other senses. This can be done from many contexts in the kernel, including kernel worker threads, etc. - File interface. Using kern_open(), return a reference to an open 'struct file' Use the calls fo_read(), fo_write(), etc. This is more abstract than the VFS interface, and strongly resembles the interface used via file descriptors (since that's what it implements). It's less functionally complete than the VFS interface, so you can't do stuff like changing the file mode, etc, directly (you have to perform them on the file's vnode). It also requires file descriptor context, so possibly one associated with a user process and then borrowed by the kernel. Linux exports a FILE stream like interface in its kernel, and for the purposes of porting the FLASK/TE components from DTOS/SELinux to FreeBSD, we also ported a subset of this functionality. Feel free to grab and reuse as appropriate in a kernel module or the like. You can find it at: http://fxr.watson.org/fxr/source/security/sebsd/ss/fileutils.c?v=TRUSTEDBSD-SEBSD http://fxr.watson.org/fxr/source/security/sebsd/ss/fileutils.h?v=TRUSTEDBSD-SEBSD Right now it just implements fopen(), fread(), and fclose(), but it would be easy to imagine implementing fwrite(), feof(), etc by wrapping the vnode interface. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
any way to reset errno?
Hello, Any way to reset errno? Thanks... Regards. -- . 0 . | Daniel Molina Wegener . . 0 | dmw at trauco dot cl 0 0 0 | http://trauco.cl/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opening and wriiting to file in Kern
--- Peter Pentchev [EMAIL PROTECTED] wrote: On Sun, Feb 06, 2005 at 04:22:41AM -0800, Kamal R. Prasad wrote: --- Scott Long [EMAIL PROTECTED] wrote: Ashwin Chandra wrote: [snip] facility. I don't see anything wrong with providing a stream (like) interface to the filesystem. While there might indeed be nothing wrong with it, besides added complexity, the traditional way to do it would be to have a userland configuration utility that communicates with the kernel module either via ioctl's on some standard device, or via ioctl's or reading/writing of a driver-specific device. This has the advantage of being a bit more portable - while different OS's implement disk/file I/O within the kernel in wildly different ways, all OS's provide relatively simple ways for a kernel module to define a new device and handle ioctl's to it, and all OS's provide basically the same userland-to-kernel interface for having a program open a device and issue ioctl's to it :) No doubt about the portability aspect. But there are situations wherein the kernel does *NOT* want userland to know that it is using the filesystem for providing some functionaality. For a device, it is indeed typical for a userland program to accompany the driver. But besides that, there are definately situations (1 of which I am dealing with) wherein there is no userland code to help one out. [snip] regards -kamal __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: any way to reset errno?
On Feb 6, 2005, at 14:21, Daniel Molina Wegener wrote: Hello, Any way to reset errno? errno = 0; :-) Regards, Frode Nordahl Thanks... Regards. -- . 0 . | Daniel Molina Wegener . . 0 | dmw at trauco dot cl 0 0 0 | http://trauco.cl/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: backporting GEOM to the 4.x branch
[EMAIL PROTECTED] wrote: What you may want to do is create a character device driver that resembles the md(4)/vn(4) mechanism: it consumes another file or device, forwards I/O from its own device node to the underlying device after performing the transformation. If possible, you'd want to attempt to provide a small and approximate subset of the GEOM API to GBDE so that you could leave GBDE as intact as possible. I have been examining the GEOM code and at this point it seems that creating a subset of the GEOM API in order to leave GBDE intact would take more effort than ripping the cryptographic mechanism out of GBDE and integrating it into vn(4). Speaking of examining code, do you guys use data flow diagrams and other visual representation systems so you can work more quickly and effectively on such a huge and complex code base? I'm using doxygen and graphviz and I have to say they're really great, as can be seen from the following g_bde_work struct example: http://manson.vistech.net/~manager/gbde/structg__bde__work.html The rest can be found at: http://manson.vistech.net/~manager/gbde/ This sort of detailed visual documentation would allow faster development while also making it easier for new developers to join the project. What do you guys think about having such documentation for the entire source tree available on the web? Having the docs regenerated automatically once a day would probably be sufficient to be useful. Regarding getting this into 4.x: I suspect the biggest concern would be forward compatibility issues. It would be substantially counter-productive to merge a feature back with a different interface/compatibility, as it would make forward upgrades harder. That is another reason why I think I should isolate the whole thing by creating a cryptographic character device driver (cvn(4)). It would also make it easier to port to DragonFly BSD. ALeine ___ WebMail FREE http://mail.austrosearch.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
GPIB: (very) basic ibfoo() library support
I needed to get some data out from some of my measurement equipment
for some $work and the hacked up userland /dev/io code I have used
for some time just didn't cut it.
So now we have the skeleton of ibfoo() support in FreeBSD. We only
support PCIIA compatible adapters, and only a very small subset of
the ibfoo() functions are implemented, but the framework has been
written so that both other hardware and more functions should be a
matter of very little work.
Completing this is on my wish-list, but only on my todo list to the
extent that I need it for something else. Help to get this more
complete is most welcome!
The wish list:
o Complete more of the ibfoo() functions.
o Support for different GPIB cards.
o IEEE488.2 API implentation.
o Manual pages. (Either just reference the NI docs or rewrite it
all to avoid copyright issues).
Reading material:
http://www.ni.com/pdf/manuals/321038g.pdf
http://www.measurementcomputing.com/gpibhelp_Lib4881.html
http://linux-gpib.sourceforge.net/doc_html/index.html
The following program should be able to pull out the identity of
any SCPI instrument which happens to sit on PAD21 on your GPIB bus,
/* compile with: cc -o ibtest ibtest.c -lgpib */
#include stdio.h
#include err.h
#include vis.h
#include gpib/gpib.h
int
main(int argc __unused, char **argv __unused)
{
int dmm;
unsigned char buf[100];
char vbuf[sizeof buf * 4];
/* DVM */
dmm = ibdev(0, 21, 0, T10s, 1, 0);
if (dmm 0)
errx(1, ibdev = %d\n, dmm);
ibwrt(dmm, *IDN?\r\n, 7);
ibrd(dmm, buf, sizeof buf - 1);
strvisx(vbuf, buf, ibcnt, VIS_WHITE | VIS_CSTYLE);
printf(%s\n, vbuf);
return (0);
}
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
i86 install images
I need someone to verify for me, the disc1 image on the main (ftp.freebsd.org) website image, I have downloaded it 3 times now, and it keeps on reporting to me, when I try to burn it, that it's the miniinst image. I'm capable of missing something obvious, so I am asking someone (anyone) else to check this, please. One item that always irks me, what's the actual name of the disk images. There is a reticence to answer this on the website, cause they're trying to make one answer do correct duty for all the arches, but what they've accomplished is managing to completely miss the mark, to leave out the main data of what's the correct actual names of the images to download. They keep on referring to the install disks, so I can't figure out what the miniinst is, or the bootonly. I have a small universe to choose from, yes, but it should be size zero. Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and SF/Fantasy. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary (on the wall at my old fraternity, Signa Phi Nothing). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i86 install images
Chuck Robey wrote: I need someone to verify for me, the disc1 image on the main (ftp.freebsd.org) website image, I have downloaded it 3 times now, and it keeps on reporting to me, when I try to burn it, that it's the miniinst image. I'm capable of missing something obvious, so I am asking someone (anyone) else to check this, please. I assume that you're talking about 5.3-R or 4.11-R? If you think that the image might be corrupt, could you verify the MD5 checksum with what was published in the release announcement? One item that always irks me, what's the actual name of the disk images. There is a reticence to answer this on the website, cause they're trying to make one answer do correct duty for all the arches, but what they've accomplished is managing to completely miss the mark, to leave out the main data of what's the correct actual names of the images to download. They keep on referring to the install disks, so I can't figure out what the miniinst is, or the bootonly. I have a small universe to choose from, yes, but it should be size zero. The general scheme is: bootonly: just the kernel and sysinstall. Equivalent to the boot floppies. Only for doing network installs miniinst: kernel, sysinstall, installation distributions, perl package. The minimum you need to install FreeBSD from a single CD. disc1: kernel, sysinstall, install distributions, lots of packages. Good for installing a desktop like Gnome or KDE. disc2: kernel, sysinstall, no install distributions, live filesystem. Good for recovering broken systems. I used it for just this a few days ago myself. The iso9660 label name sometimes gets screwed up when we cut releases. We should be better about this, but it's not something that is always obvious. We are working on a new scheme that combines disc2 and miniinst and puts all packages on disc2. There will no longer be a miniinst after that, just disc1, disc2, and possbily bootonly. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i86 install images
Chuck Robey [EMAIL PROTECTED] writes: One item that always irks me, what's the actual name of the disk images. There is a reticence to answer this on the website, cause they're trying to make one answer do correct duty for all the arches, but what they've accomplished is managing to completely miss the mark, to leave out the main data of what's the correct actual names of the images to download. They keep on referring to the install disks, so I can't figure out what the miniinst is, or the bootonly. I have a small universe to choose from, yes, but it should be size zero. disc1 has the sysinstall, the distribution and the most popular packages. miniinst only has sysinstall and the distribution, without any packages. bootonly only has boot blocks and loader (useful for system recovery). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sharing memory between ithread and userland
Have you marked the dev_status struct volatile so that the compiler is forced to re-fetch from memory the values? The example you provided didn't have this... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: any way to reset errno?
In message: [EMAIL PROTECTED] Daniel Molina Wegener [EMAIL PROTECTED] writes: :Any way to reset errno? errno = 0; Routines that return an error status in errno generally don't set it to 0 to mean no error. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Hackers] Re: any way to reset errno?
M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Daniel Molina Wegener [EMAIL PROTECTED] writes:
:Any way to reset errno?
errno = 0;
Routines that return an error status in errno generally don't set it
to 0 to mean no error.
Which implies errno should never need to be set to zero since the
convention is to only look at errno if a system call fails. The only
time errno needs to be explicitly set (to any value) is when preserving
the error value between system calls. Such as:
if (write(fd, buf, len) 0) {
int saved_errno;
saved_errno = errno;
close(fd); /* ignore any error */
errno = saved_errno;
return -1;
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i86 install images
On Sun, 6 Feb 2005, Scott Long wrote: Chuck Robey wrote: I need someone to verify for me, the disc1 image on the main (ftp.freebsd.org) website image, I have downloaded it 3 times now, and it keeps on reporting to me, when I try to burn it, that it's the miniinst image. I'm capable of missing something obvious, so I am asking someone (anyone) else to check this, please. I assume that you're talking about 5.3-R or 4.11-R? If you think that the image might be corrupt, could you verify the MD5 checksum with what was published in the release announcement? One item that always irks me, what's the actual name of the disk images. There is a reticence to answer this on the website, cause they're trying to make one answer do correct duty for all the arches, but what they've accomplished is managing to completely miss the mark, to leave out the main data of what's the correct actual names of the images to download. They keep on referring to the install disks, so I can't figure out what the miniinst is, or the bootonly. I have a small universe to choose from, yes, but it should be size zero. The general scheme is: bootonly: just the kernel and sysinstall. Equivalent to the boot floppies. Only for doing network installs miniinst: kernel, sysinstall, installation distributions, perl package. The minimum you need to install FreeBSD from a single CD. disc1: kernel, sysinstall, install distributions, lots of packages. Good for installing a desktop like Gnome or KDE. disc2: kernel, sysinstall, no install distributions, live filesystem. Good for recovering broken systems. I used it for just this a few days ago myself. The iso9660 label name sometimes gets screwed up when we cut releases. We should be better about this, but it's not something that is always obvious. We are working on a new scheme that combines disc2 and miniinst and puts all packages on disc2. There will no longer be a miniinst after that, just disc1, disc2, and possbily bootonly. 3 different responses, all 3 entirely professional, and this is the reason why FreeBSD is never going to be entirely removed by Linux, because the support is so GREAT! Anyhow, I do my downloading using my Mac machine, and it's reporting the, say for the disc1, it's miniinst and for disc2, it's reporting LiveFS. I know it's not important what label's on the disc, as long as it's not part of the install, but having the names not only being wrong. but actually overwriting good names, that's not very good. If I was root, I would want that fixed, it would embarrass me. Just before I sign off here, once more, thanks for the gret response! Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and SF/Fantasy. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary (on the wall at my old fraternity, Signa Phi Nothing). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Hackers] Re: any way to reset errno?
In message: [EMAIL PROTECTED]
Julian Cowley [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
: In message: [EMAIL PROTECTED]
: Daniel Molina Wegener [EMAIL PROTECTED] writes:
: :Any way to reset errno?
:
: errno = 0;
:
: Routines that return an error status in errno generally don't set it
: to 0 to mean no error.
:
: Which implies errno should never need to be set to zero since the
: convention is to only look at errno if a system call fails. The only
: time errno needs to be explicitly set (to any value) is when preserving
: the error value between system calls. Such as:
:
: if (write(fd, buf, len) 0) {
: int saved_errno;
:
: saved_errno = errno;
: close(fd); /* ignore any error */
: errno = saved_errno;
: return -1;
: }
Well, to portably[*] use some of the math(3) routines in libc, you
need to set it to 0 before calling them (strtol, et al come to mind).
Otherwise you are correct. In fact, it is generally incorrect to
write code like:
errno = 0;
close(fd);
if (errno != 0)
because errno isn't necessarily valid even if it has changed in that
case...
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question: tracking filesystem changes?
Hi, No, won't do the trick either. I cannot afford setting up watchdogs for every file or even every directory. And I'm essentially interested in every one of them (for mirroring purposes). A more general approach is needed. E.g., if an unlink call is issued and an inode is within a particular filesystem (luckily, most of our data already lives on or can be easily moved to a separate filesystem), a notice is sent to some userland daemon: file /www/xxx/yyy.shtml is unlinked. Or opened for writing, or renamed... etc. The file is then scheduled for distribution to mirrors. The idea seems simple and straightforward, yet I don't know if it is achievable. The essential part is obtaining the full pathname of the file (won't bother with hardlinks at first, they aren't used here). Could that be done with the FreeBSD's filesystem (vnode/vfs?) code? (which I'm not familiar with) The TrustedBSD Audit code should be able to fill this need -- the goal of the Audit code is to be able to track security critical events in a configurable way, so file open/link/symlink/unlink operations are an important subset of that. We hope to integrate the Audit code into 6.x in the next few months, and then (in as much as is possible given kernel ABI requirements) merge for 5.5. However, this is some time away still, so presumably can't help in the short term. The result, though, is an event stream file that's mechanically parseable, and the even stream can be configured to indicate which types of events are important at a fairly fine granularity. Sounds great. But i have similar tasks (not so huge amount of files) and i'd prefer to extend kqueue/kevent with EVFILT_INODE filter to have ability to monitor changes in file without opening it. -- Nick Strebkov Public key: http://humgat.org/~nick/pubkey.txt fpr: 552C 88D6 895B 6E64 F277 D367 8A70 8132 47F5 C1B6 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i86 install images
Chuck Robey wrote: Anyhow, I do my downloading using my Mac machine, and it's reporting the, say for the disc1, it's miniinst and for disc2, it's reporting LiveFS. I know it's not important what label's on the disc, as long as it's not part of the install, but having the names not only being wrong. but actually overwriting good names, that's not very good. If I was root, I would want that fixed, it would embarrass me. FYI, within the past 2 weeks I downloaded the 5.3-RELEASE image to an OSX mac and successfully burned it, not sure exactly what site it was. I never looked at the label however. One thing to remember though, when burning ISOs on an OSX mac the best way I've found it to open up a terminal (Applications / Utilities, if I remember correctly) and then do 'hdutil burn isoname' -- Ryan Sommers [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question: tracking filesystem changes?
On Mon, 7 Feb 2005, Nick Strebkov wrote: The TrustedBSD Audit code should be able to fill this need -- the goal of the Audit code is to be able to track security critical events in a configurable way, so file open/link/symlink/unlink operations are an important subset of that. We hope to integrate the Audit code into 6.x in the next few months, and then (in as much as is possible given kernel ABI requirements) merge for 5.5. However, this is some time away still, so presumably can't help in the short term. The result, though, is an event stream file that's mechanically parseable, and the even stream can be configured to indicate which types of events are important at a fairly fine granularity. Sounds great. But i have similar tasks (not so huge amount of files) and i'd prefer to extend kqueue/kevent with EVFILT_INODE filter to have ability to monitor changes in file without opening it. What mechanism do you have in mind for KQueue to notify you as to which file had an event? Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ATA_IDENTIFY timed out on ASUS P4VP-MX
Recently one of my clients get a new (very cheap) P4VP-MX wich uses a VIA VT8235 Southbridge. This machine is not detecting (identify) ATA disk under 5.3. I have tested with 5.3-STABLE and 5.3-RELEASE, with 4.X it works. I tried with different disks and with CDROM, but nothing works. The same disk run on another machines (including a P4SP-MX wich uses SIS chipset) and 4.X run normaly. I have do some code debug, and ata_getparam() get no return (no interrupt is generated - ata_interrupt() never run). The workaround of PR/73706 not work for me (my secondary ATA also fail) and break another machine on tests. I'm playing with interrupt routing, but i cant get it working. Also tried with dma, acpi, pci.enable_io_modes and apic disabled. There is no error on dmesg until ATA_IDENTIFY timed out. Any ideas / workaround ? Thanks, Luiz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Opening and wriiting to file in Kern
If you mist do this, the general set of steps are: 1. use namei() to convert a pathname to a vnode 2. Use vn_open(), vn_rdwr(), and vn_close() to operate on the vnode. 3. Observe proper vnode locking and reference counting with vref(), vn_lock(), and vput() Take a look at sys/kern/kern_ktrace.c or sys/kern/kern_alq.c for a template. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Opening files in Kernel Mode: help
So this is the code I got from help from you hackers out there and templates in the /kern library. This compiles but causes a kernel panic. I was wondering if any of you knew why this was happening and if I am calling all the virtual node functions correctly? ***CODE BELOW register struct proc *p; struct nameidata nd; int flags = FWRITE | O_CREAT; struct ucred *uc; static struct ucred *acctcred; char data[1000]; acctcred = crhold(curthread-td_ucred); uc = crhold(acctcred); NDINIT(nd, CREATE, FOLLOW, UIO_SYSSPACE, /home/achandra/LOG, curthread); vn_open(nd, flags, 0,-1); NDFREE(nd, NDF_ONLY_PNBUF); vref(nd.ni_vp); VOP_LEASE(nd.ni_vp, curthread, uc, LEASE_WRITE); sprintf(data, %s, asdsada); vn_rdwr(UIO_WRITE, nd.ni_vp, (caddr_t)data, strlen(data), (off_t)0, UIO_SYSSPACE, IO_APPEND|IO_UNIT, uc, NOCRED, (int *)0, curthread); vrele(nd.ni_vp); crfree(uc); vn_close(nd.ni_vp, flags, curthread-td_ucred, curthread); ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question: tracking filesystem changes?
No, won't do the trick either. I cannot afford setting up watchdogs for every file or even every directory. And I'm essentially interested in every one of them (for mirroring purposes). A more general approach is needed. E.g., if an unlink call is issued and an inode is within a particular filesystem (luckily, most of our data already lives on or can be easily moved to a separate filesystem), a notice is sent to some userland daemon: file /www/xxx/yyy.shtml is unlinked. Or opened for writing, or renamed... etc. The file is then scheduled for distribution to mirrors. The idea seems simple and straightforward, yet I don't know if it is achievable. The essential part is obtaining the full pathname of the file (won't bother with hardlinks at first, they aren't used here). Could that be done with the FreeBSD's filesystem (vnode/vfs?) code? (which I'm not familiar with) Nick, You might want to take a look at Matt Dillon's journalling work in DragonFly BSD. Their journalling layer can send a filesystem operations change stream (essentially, vfsops such as create, write, truncate, rmdir, etc) to any file descriptor, which makes filesystem changes easy to track and replicate to other machines. See the Description of the Journaling topology thread at http://leaf.dragonflybsd.org/mailarchive/kernel/2004-12/dateindex.html Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA_IDENTIFY timed out on ASUS P4VP-MX
Luiz Otavio Souza wrote: Recently one of my clients get a new (very cheap) P4VP-MX wich uses a VIA VT8235 Southbridge. This machine is not detecting (identify) ATA disk under 5.3. I have tested with 5.3-STABLE and 5.3-RELEASE, with 4.X it works. I tried with different disks and with CDROM, but nothing works. The same disk run on another machines (including a P4SP-MX wich uses SIS chipset) and 4.X run normaly. I have do some code debug, and ata_getparam() get no return (no interrupt is generated - ata_interrupt() never run). The workaround of PR/73706 not work for me (my secondary ATA also fail) and break another machine on tests. I'm playing with interrupt routing, but i cant get it working. Also tried with dma, acpi, pci.enable_io_modes and apic disabled. There is no error on dmesg until ATA_IDENTIFY timed out. Any ideas / workaround ? Please try the ATA-mkIII patches+tarfile I announced last week on -current and -stable.. -- -Søren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i86 install images
On Sun, Feb 06, 2005 at 01:50:34PM -0700, Scott Long wrote.. Chuck Robey wrote: I need someone to verify for me, the disc1 image on the main (ftp.freebsd.org) website image, I have downloaded it 3 times now, and it keeps on reporting to me, when I try to burn it, that it's the miniinst image. I'm capable of missing something obvious, so I am asking someone (anyone) else to check this, please. I assume that you're talking about 5.3-R or 4.11-R? If you think that the image might be corrupt, could you verify the MD5 checksum with what was published in the release announcement? One item that always irks me, what's the actual name of the disk images. There is a reticence to answer this on the website, cause they're trying to make one answer do correct duty for all the arches, but what they've accomplished is managing to completely miss the mark, to leave out the main data of what's the correct actual names of the images to download. They keep on referring to the install disks, so I can't figure out what the miniinst is, or the bootonly. I have a small universe to choose from, yes, but it should be size zero. The general scheme is: bootonly: just the kernel and sysinstall. Equivalent to the boot floppies. Only for doing network installs miniinst: kernel, sysinstall, installation distributions, perl package. The minimum you need to install FreeBSD from a single CD. disc1: kernel, sysinstall, install distributions, lots of packages. Good for installing a desktop like Gnome or KDE. For 4.11R there were two disc1 images, one with KDE, one with GNOME. The iso file names reflect this. -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
