PPP patch (CHAP81 + MPPE)
Hi! Here is a patch attached (made from current from 2813). Patch makes ppp able to respond and initiate MS-CHAP-v2 authentication and supports MPPE encryption protocol. With all these ppp can participate in MS VPN. Please look at this, and tell me what you think? Bye! ppp-mppe-patch.gz
Re: mount_hpfs not built by default
On Sat, 12 Aug 2000, Alexander Langer wrote: > Hello! > > In PR docs/20369 it was mentioned that mount_hpfs isn't built by > default. > > Am I missing something? Why not? From the cvs-logs, it seems, it has > just been forgotten :) > However, I'm asking because maybe I missed a discussion back in > December. > I think there are too few people who really use HPFS. So it doesn't worth. Also, i'm not sure it's working at all. Sorry. I don't have HPFS partitions any more, so i even can't verify if it works. Bye. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
nullfs patch
Hi! Here is a patch, it seems it fix some bugs in nullfs. At least i was able to make kernel on nullfs mounted filesystem. All results are welcome! Good luck! patch
Mapping files into kernel memory space
Hi! I am writing an FS driver, and i need often to compose some FS internal information from fragments. The first idea was to malloc a poll and copy data from buffers, returned by bread(). But it seems to me simplier to write VOP_BMAP, VOP_STRATEGY, and then map needed portion into kernel space. I suppose there is no major problems, isn't it? So the question is: Is it a good idea at all? Will it be faster/slower? Good luck. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Where to put HPFS driver?
Hi! Promised somewhere in spring, i am now almost ready to put HPFS driver into current. So i have question: Where have to go driver sources src/sys/hpfs or src/sys/i386/hpfs, or something else ? Where have to go mount_hpfs: src/sbin/i386/mount_hpfs? As i will patch mountd.c to support hpfs, do we need ifdef I386 there? And in the src/sys/modules/Makefile and others? Good luck. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FS Driver writing tactic
Hi FS Guru! Is this a good tactic to write working VOP_BMAP and VOP_STRATEGY handlers, and implement VOP_READ and VOP_WRITE via bread and bwrite of own vnodes? Bye. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How can i fail buf?
On Mon, 31 May 1999, Bruce Evans wrote: > This isn't solved. It was less serious before rev.1.196 of vfs_bio.c > when B_ERROR buffers were discarded insead of re-dirtied in the above > code fragment. See also PR 11697, and about 20 PRs reporting problems > with i/o errors and EOF "errors" (ENOSPC/EINVAL) for (mis)using buffered > devices (especially fd0). > Why they have done so? B_ERROR have to mean unrecoverable error, doesn't it? Or we need something like Writing to ... at ... failed. (A)bort, (R)etry, (I)gnore? :-) > I use the following variant of the patch in PR 11697: > > [patch skipped] > Will it ever included in current? > This fixes the primary problem in all cases except the most interesting one: > for real i/o errors. It doesn't touch the secondary problem that most > VOP_FSYNC() routines don't try hard enough to write all dirty buffers in > the MNT_WAIT case, so vinvalbuf() may panic. > As i see, we need some B_FATAL flag, that will signal brelse to do not redirty buf, for example to set when media in fd was changed. About F_SYNC: usually they do, they try very hard to free dirty queue, look at msdosfs_vnops.c, and 'man VOP_FSYNC' pseudocode. Pseudocode even loops infinitly if there is a not writable buf. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
How can i fail buf?
Hi!
The problem is following:
FS driver recieves VOP_FSYNC request,
then it scan the queue and pick up dirty buffers to
bwrite(bp) them. bwrite calls VOP_STRATEGY,
FS's strategy routine is trying to VOP_BMAP buf, and
fails (suppose it fails), then xxfs_strategy do:
bp->b_error = error;
bp->b_flags |= B_ERROR;
biodone(bp);
return(bp);
(Looks right, at least IMO)
But:
biodone will not rel*se(bp), as it is not B_ASYNC,
then it returns to bwrite, where it will brelse(bp) after
biowait(bp). Then bp will come to brelse with B_ERROR set.
in the begining, brelse:
...
if ((bp->b_flags & (B_READ | B_ERROR)) == B_ERROR) {
bp->b_flags &= ~B_ERROR;
bdirty(bp);
} ...
then buffer returns to dirty queue, and is dirty, all
repeates infinite.
How this is solved?
Sorry if i miss something obvious...
Sorry for bad english...
Bye
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
HPFS driver for FreeBSD needs testers.
Hi! There is a driver to read from HPFS partition at: http://iclub.nsu.ru/~semen/hpfs/hpfs-0.2b.tgz Testers are welcome. Bye. P.S. We can put it in current, and i'll support it. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Nt source licenses...
On Sun, 16 May 1999, Narvi wrote: > > On Sat, 15 May 1999, Alfred Perlstein wrote: > > > On Sat, 15 May 1999, Narvi wrote: > > > > > > > > On Fri, 14 May 1999, Garance A Drosehn wrote: > > > > > > > At 3:51 PM +0700 5/12/99, Ustimenko Semen wrote: > > > > > Are we going to get this license? I am interested in NTFS > > > > > source code a lot... > > > > > > > > I would be very careful about getting an NT source license if > > > > your intention is to write NTFS support for some other operating > > > > system. Microsoft is not doing this licensing for the benefit of > > > > mankind, they are doing it to attract college-type users to > > > > sticking with WinNT over open-source unixes. > > > > > > > > The last thing we need is some code from WinNT which causes us > > > > to be sued by Microsoft... > > > > > > > > > > It would probably be very unwise for the project to get get the licence. > > > > > > However, considering that we support loadable filesystem modules, somebody > > > adventurous enough can get the licence and write a (separate distributed, > > > possibly even only as binary) module. > > > > > > Downloading a kld module from the net definately does not "taint" your > > > mind. > > > > I'm unsure what the fuss is over, don't we have a kld to read NTFS already? > > > > How about writing? > Yes, there is no writing. The problem is that NTFS is ``Logging'' file system. Current documentation is totaly reverse developed, and it's very difficult to hack $LogFile... Anyway we have to read the license before discussing. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Nt source licenses...
Hi, On Tue, 11 May 1999, Luigi Rizzo wrote: > Hi, > maybe i am the last one in the world to know, but were you guys aware > of this: > > http://research.microsoft.com/programs/NTSrcLicInfo.htm > > Microsoft makes Windows NT source code available to universities > and other "not-for-profit" research institutions at no charge. > Currently, there are over 55 universities and government agencies > with source licenses. > ... > > I still have to check the exact conditions though. The above web page > says this: > > Features of the license > > * No cost > * Intellectual property created with the use of NT source code is >owned by the researcher. > * Source licensees can share source or other source-based work >with other NT Source licensees. > * Source is licensed to the requesting organization, not individuals >to insure broad internal access. > * No employment restrictions as the result of viewing or using the >source. > Are we going to get this license? I am interested in NTFS source code a lot... P.S. What's happening with MS? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
swaper(?) bug (or feature) ?
Hi, running 4.0-current from late january i've got folloing: top tells: ... Mem: 11M Active, 952K Inact, 5712K Wired, 640K Cache, 3348K Buf, 11M Free Swap: 106M Total, 106M Used, 232K Free, 99% Inuse ... regardless 11M Free, almost all programs fail: # cat cat: Cannot allocate memory luck is that kill works :-) after i kill the process eating all swap space all went OK. that's all. Sorry if this was disscussed before... (I haven't found anything like this) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: About to commit NTFS driver
On Thu, 28 Jan 1999, Mike Smith wrote: > > > > Are there any disagrees with an idea to commit a NTFS > > driver into current: > > > > I can commit/maintain driver mentioned at > > http://www.freebsd.org/projects/ > > > > Driver is readonly, specialy developed for freebsd, > > supports most of NTFS's features. > > Source is at http://iclub.nsu.ru/~semen/ntfs/ > > Sounds like a good idea. Do you have a reviewer? > Looks like not. David O'Brien have just showed me points to fix. May be he will be? He also noticed, that it doesn't work under 4.0-current, so it will take more time. P.S. What about writing on NTFS volume, i think we can do it, but without logging, as NT does. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
About to commit NTFS driver
Hello! Are there any disagrees with an idea to commit a NTFS driver into current: I can commit/maintain driver mentioned at http://www.freebsd.org/projects/ Driver is readonly, specialy developed for freebsd, supports most of NTFS's features. Source is at http://iclub.nsu.ru/~semen/ntfs/ Thank you! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: What about inclusion of NTFS RO driver into current
Sorry, for self follow up, I haven't explain thougth clean enought. I've spoken of almost ready NTFS driver, that is reported to work for near 4-5 people. It was for stable and current (don't know how to call them now) with little difference. Thank you To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
What about inclusion of NTFS RO driver into current
Hello! Possibly we can include it also in RELENG_2_2? Bye. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: sys/kern/kern_linker.c patch
Sorry for self reply. Patch isn't good enougth:-) becouse linker_file_unload() deallocates lf structure's memory... so lf->userrefs-- may cause page fault or whatever else. (I wonder how that didn't happened) Look at this one: *** kern_linker.c.orig Mon Jan 18 17:22:39 1999 --- kern_linker.c Mon Jan 18 18:14:28 1999 *** *** 655,660 --- 655,662 } lf->userrefs--; error = linker_file_unload(lf); + if(error) + lf->userrefs++; } else error = ENOENT; To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
sys/kern/kern_linker.c patch
Imagine: I'm trying to unload KLD module, it is busy: # kldunload -n ntfs kldunload: can't unload file: Device busy After this point i'll never get module unloaded becouse kldunload() in sys/kern/kern_linker.c has already decremeted lf->userrefs. I'll get only this messages: # kldunload -n ntfs Jan 18 17:10:13 ws21 /kernel: linkerunload: attempt to unload file which was not loaded by user kldunload: can't unload file: Device busy Here is patch. *** kern_linker.c.orig Mon Jan 18 17:22:39 1999 --- kern_linker.c Mon Jan 18 16:40:33 1999 *** *** 653,660 error = EBUSY; goto out; } - lf->userrefs--; error = linker_file_unload(lf); } else error = ENOENT; --- 653,662 error = EBUSY; goto out; } error = linker_file_unload(lf); + if(error) + goto out; + lf->userrefs--; } else error = ENOENT; To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
