Re: if_ethersubr.c: if_ierrors -> if_iqdrops?
On Mon, 8 Nov 2021, Jason Thorpe wrote: On Nov 7, 2021, at 11:07 PM, RVP wrote: So, I hacked up a small patch to put most of these into the "if_iqdrops" bucket. The rest (following FreeBSD) remain as errors. LGTM! On Mon, 8 Nov 2021, Christos Zoulas wrote: As far as I'm concerned, you can silently chuck most of these errors away--like FreeBSD does, or classify them as "dropped" like Linux does. Either way is fine with me--just not "if_ierrors": that's too confusing. I think that the patch makes sense... OK, so discarded packets are fine as `if_iqdrops'. Otherwise, a kernel w/o vlan (or netatalk, carp, ...) compiled in will show: $ ifconfig -v alc0 alc0: flags=0x8843 mtu 1500 ec_capabilities=0x1 ec_enabled=0 address: 50:46:5d:32:67:54 media: Ethernet autoselect (100baseTX full-duplex,flowcontrol,rxpause,txpause) status: active input: 2502 packets, 488042 bytes, 1935 multicasts, 821 queue drops output: 611 packets, 133649 bytes, 43 multicasts inet6 fe80::5246:5dff:fe32:6754%alc0/64 flags 0 scopeid 0x1 inet 192.168.68.121/24 broadcast 192.168.68.255 flags 0 $ Maybe we should have a separate `if_idiscard'? Or is that too fine a distinction? Thanks, -RVP
Re: Mail.app idiocy [was Re: UNIX kernel notification system]
On Mon, Oct 03, 2011 at 04:02:16PM -0400, Mouse wrote: > One of my correspondents at work has exactly this problem when I send > nicely formatted text. > > > This is, admittedly, less evil than the Android mail client's > > unalterable behavior of base64-encoding *all* message data, even that > > which would be perfectly readable as plain ASCII text. > > I don't think so. That at least is correctly labeled and thus _can_ be > mechanically corrected for, by those for whom it needs correction. > This is a case of Mail.app suckering its users into sending out > mislabeled mail without even telling them it's doing so. The most evil mail I get is mail that is formatted with HTML but without any headers nor MIME header making it nearly impossible to just auto format it without resorting to hacks like piping it to say lynx Reinoud
Re: UNIX kernel notification system
On Mon, Oct 03, 2011 at 02:36:37PM -0400, Thor Lancelot Simon wrote: > On Mon, Oct 03, 2011 at 11:31:17AM -0700, Erik Fair wrote: > > > > On Oct 3, 2011, at 00:56 , Mouse wrote: > > > > > [Do you really mean to use paragraph-length lines? I'd suggest against > > > it; they impair readability significantly, at least for me. Manually > > > rewrapped in the quotes below.] > > > > less(1) (or more(1)) doesn't take care of you? > > Since those are not the pagers I use for my mail, no, they don't take > care of me, either. Certainly not when responding, in which case I am > forced to reformat your text by hand in order to insert the ">" > character on each line to mark quoted material. Since I use vim as my mail editor, I use `gqap' to auto reformat things I want to quote; it reflows and auto inserts the > in front. Reinoud
Re: if_ethersubr.c: if_ierrors -> if_iqdrops?
> On Nov 7, 2021, at 11:07 PM, RVP wrote: > > So, I hacked up a small patch to put most of these into the > "if_iqdrops" bucket. The rest (following FreeBSD) remain as errors. LGTM! -- thorpej
Re: write alignment matters?
On Fri, Jun 24, 2011 at 04:39:13PM +, David Holland wrote: > On Fri, Jun 24, 2011 at 11:33:51AM -0400, der Mouse wrote: > > >> Oh, I was talking about current NetBSD where block devices are a > > >> second class citizen, soon to be abolished if someone finds enough > > >> round tuits. > > > Yes, so it keeps being said. It would truly be a pity to see that > > > happen. > > > > Why? > > Why which? :-) > > The current problem is that the block device is connected to the old > pre-UBC buffer cache now used only for metadata blocks, so various > problems (consistency, starvation, etc.) can occur if you start using > it for bulk I/O. There's also a problem that the buffer cache code > wasn't ever designed to cope with removable devices, so bad things > happen if you try to use the block device for something that isn't > there (e.g. a floppy drive with no media in it) or that you eject > before writeback has completed. Maybe a revolutionary thing to say, but can't we make the block devices use UBC too? Its not that different from reading a file after all. Existing users of the buffer-cache can then be given a method of coupling some buffers to a node instead of using the negative number scheme. Directory contents can also be stored in UBC, fs/udf has done that as long as it exists. > I assume the reason it would be a pity to see it go is that (when > working properly) it's useful functionality, even if used rarely or > only in specialized circumstances. Also, for applications like online > defrag or whatnot, using a (properly unified) block device is delicate > but using a raw device is entirely infeasible. indeed > My current intent is to tackle the buffer cache when/if I ever finish > grinding namei and namei-related vfs stuff, because the lack of full > unification bugs me and the build quality of the old buffer code > concerns me. see above, Reinoud
