Re: [PATCH net-next] Remove DECnet support from kernel
On Monday 2023-01-09 08:04, Jiri Slaby wrote:
> On 18. 08. 22, 2:43, Stephen Hemminger wrote:
>> DECnet is an obsolete network protocol
>
> this breaks userspace. Some projects include linux/dn.h:
>
> https://codesearch.debian.net/search?q=include.*linux%2Fdn.h=0
>
> I found Trinity fails to build:
> net/proto-decnet.c:5:10: fatal error: linux/dn.h: No such file or directory
> 5 | #include
>
> Should we provide the above as empty files?
Not a good idea. There may be configure tests / code that merely checks for
dn.h existence without checking for specific contents/defines. If you provide
empty files, this would fail to build:
#include "config.h"
#ifdef HAVE_LINUX_DN_H
# include
#endif
int main() {
#ifdef HAVE_LINUX_DN_H
socket(AF_DECNET, 0, DNPROTO_NSP); // or whatever
#else
...
#endif
}
So, with my distro hat on, outright removing header files feels like the
slightly lesser of two evils. Given the task to port $arbitrary software
between operating systems, absent header files is something more or less
"regularly" encountered, so one could argue we are "trained" to deal with it.
But missing individual defines is a much deeper dive into the APIs and
software to patch it out.
Re: [PATCH v2 7/7] uapi: export all headers under uapi directories
On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote: >Le 09/01/2017 à 13:56, Christoph Hellwig a écrit : >> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: >>> Regularly, when a new header is created in include/uapi/, the developer >>> forgets to add it in the corresponding Kbuild file. This error is usually >>> detected after the release is out. >>> >>> In fact, all headers under uapi directories should be exported, thus it's >>> useless to have an exhaustive list. >>> >>> After this patch, the following files, which were not exported, are now >>> exported (with make headers_install_all): >> >> ... snip ... >> >>> linux/genwqe/.install >>> linux/genwqe/..install.cmd >>> linux/cifs/.install >>> linux/cifs/..install.cmd >> >> I'm pretty sure these should not be exported! >> >Those files are created in every directory: >$ find usr/include/ -name '\.\.install.cmd' | wc -l >71 That still does not mean they should be exported. Anything but headers (and directories as a skeleton structure) is maximally suspicious.
Re: therm_pm72 units, interface
On Wednesday 2012-08-15 23:36, Benjamin Herrenschmidt wrote: BTW... On a somewhat related note ... if you happen to have a spare Xserve G5 PSU I'm interested :-) I tried pulling it out, but the PSU stuck so hard in the ATX-like mainboard power socket that removing the PSU would have probably meant ripping apart the MB. Anyhow, I did a PMU reset (there's a documented button on the MB), and 'lo, it seems the auto-poweroff that plagued this machine are gone - but I'll need a longer uptime than 2 hours to find out. Meanwhile, I run Linux 3.7.1 and the software side changed somewhat. windfarm_rm31 seems to no longer calm the fans down once loaded, whereas therm_pm72 on Linux 3.0 did so. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Thursday 2012-08-16 22:51, Benjamin Herrenschmidt wrote: You can try netbooting... OF netboot is limited to 4M sized zImages which can be a bit tough nowadays, but modern yaboot can netboot larger files. Another option is USB sticks. I can just exploit the fact that the machine will run for about an hour when it has had a cooldown night. Except that 3.5, as I already expected by scary mails read on linux-kernel, looked dangerous to use. Here is a boot-time hang. --- Apple RackMac3,1 5.1.7f2 BootROM built on 12/09/04 at 10:58:45 Copyright 1994-2004 Apple Computer, Inc. All Rights Reserved. Welcome to Open Firmware, the system time and date is: 14:03:41 08/17/2012 To continue booting, type mac-boot and press return. To shut down, type shut-down and press return. ok 0 boot load-size=97d adler32=7e30648e parsing CHRP-BOOT evaluating BOOT-SCRIPT DART table allocated at: c0007f00 Using PowerMac machine description Found initrd at 0xc240:0xc2783e10 Found U3 memory controller host bridge @ 0xf800 revision: 0x35 Mapped at 0xd8008000 Found a K2 mac-io controller, rev: 96, mapped at 0xd8008005 PowerMac motherboard: XServe G5 DART IOMMU initialized for U3 type chipset bootconsole [udbg0] enabled CPU maps initialized for 1 thread per core Starting Linux PPC64 #1 SMP Wed Aug 15 21:49:59 UTC 2012 (4904750) - ppc64_pft_size= 0x0 physicalMemorySize= 0x8000 htab_address = 0xc0007c00 htab_hash_mask= 0x3 - Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.5.2-5-ppc64 (geeko@buildhost) (gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) ) #1 SMP Wed Aug 15 21:49:59 UTC 2012 (4904750) [boot]0012 Setup Arch Found U3-AGP PCI host bridge. Firmware bus number: 240-255 PCI host bridge /pci@0,f000 ranges: MEM 0xf100..0xf1ff - 0xf100 IO 0xf000..0xf07f - 0x MEM 0xb000..0xbfff - 0xb000 Can't get bus-range for /ht@0,f200, assume bus 0 Found U3-HT PCI host bridge. Firmware bus number: 0-239 PCI host bridge /ht@0,f200 (primary) ranges: via-pmu: Server Mode is disabled PMU driver v2 initialized for Core99, firmware: 0c nvram: Checking bank 0... nvram: gen0=508, gen1=507 nvram: Active bank is: 0 nvram: OF partition at 0x410 nvram: XP partition at 0x1020 nvram: NR partition at 0x1120 Zone ranges: DMA [mem 0x-0x7fff] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x-0x7fff] [boot]0015 Setup Done PERCPU: Embedded 2 pages/cpu @c170 s85504 r0 d45568 u524288 Built 1 zonelists in Node order, mobility grouping on. Total pages: 32740 Policy zone: DMA Kernel command line: root=/dev/disk/by-label/silvroot sysrq=511 console=ttyPZ0,57600 console=tty0 PID hash table entries: 4096 (order: -1, 32768 bytes) freeing bootmem node 0 Memory: 2012160k/2097152k available (17152k kernel code, 84992k reserved, 1984k data, 3243k bss, 5952k init) Hierarchical RCU implementation. CONFIG_RCU_FANOUT set to non-default value of 32 RCU dyntick-idle grace-period acceleration is enabled. NR_IRQS:512 nr_irqs:512 16 mpic: Setting up MPIC MPIC 1version 1.2 at 8004, max 2 CPUs mpic: ISU size: 120, shift: 7, mask: 7f mpic: Initializing for 120 sources mpic: Setting up MPIC MPIC 2version 1.2 at f804, max 2 CPUs mpic: ISU size: 124, shift: 7, mask: 7f mpic: Initializing for 124 sources /u3@0,f800/mpic@f804: hooking up to IRQ 56 clocksource: timebase mult[1e05] shift[24] registered Console: colour dummy device 80x25 console [tty0] enabled, bootconsole disabled console [ttyPZ0] enabled allocated 524288 bytes of page_cgroup please try 'cgroup_disable=memory' option if you don't want memory cgroups pid_max: default: 32768 minimum: 301 Security Framework initialized AppArmor: AppArmor initialized Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes) Mount-cache hash table entries: 4096 Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys net_cls Initializing cgroup subsys blkio Initializing cgroup subsys perf_event PowerMac SMP probe found 2 cpus KeyWest i2c @0xf8001003 irq 16 /u3@0,f800/i2c@f8001000 channel 0 bus multibus channel 1 bus multibus KeyWest i2c @0x80018000 irq 26 /ht@0,f200/pci@3/mac-io@7/i2c@18000 channel 0 bus multibus PMU i2c /ht@0,f200/pci@3/mac-io@7/via-pmu@16000/pmu-i2c channel 1 bus multibus channel 2 bus multibus Processor timebase sync using Pulsar i2c clock mpic: requesting IPIs... PPC970/FX/MP
Re: therm_pm72 units, interface
On Wednesday 2012-08-15 23:35, Benjamin Herrenschmidt wrote: XServe G5 of mine started powering off more or less randomly BTW. There's a new windfarm driver for these in recent kernels... Appart from that, the trip points are coming from a calibration EEPROM, you may want to tweak the driver to warn a bit earlier or that sort of things ? (Or just to print more things out ?) If you have more things to print/offer via sysfs, I'm all for it. The XsG5 really has (by looking into the casing): 1 PCI Fan, 6 center fans, 1 PSU intake and 1 PSU outblow fan (this last one seems rather slow-turning, but maybe that's normal). It is not quite clear which is which in the sysfs display. What I did figure out: at the PROM, fans run at what seems to be full speed (some 8000-9000 rpm?). Once Linux and therm_pm72 are loaded, the fans settle down towards 4000 rpm, and if the machine has warmed up, that is then when it powers off. (The kernel is indeed 3.4. I now need to figure out how to place a new kernel on it without it powering off inbetween.) $ cd /sys/devices/temperature; grep '' *; backside_fan_pwm:32 backside_temperature:54.000 cpu0_current:34.423 cpu0_exhaust_fan_rpm:5340 cpu0_intake_fan_rpm:5340 cpu0_temperature:72.889 cpu0_voltage:1.252 cpu1_current:34.179 cpu1_exhaust_fan_rpm:4584 cpu1_intake_fan_rpm:4584 cpu1_temperature:68.526 cpu1_voltage:1.259 dimms_temperature:53.000 grep: driver: Er en filkatalog modalias:platform:temperature grep: power: Er en filkatalog slots_fan_pwm:20 slots_temperature:38.500 grep: subsystem: Er en filkatalog uevent:DRIVER=temperature uevent:OF_NAME=fan uevent:OF_FULLNAME=/u3@0,f800/i2c@f8001000/fan@15e uevent:OF_TYPE=fcu uevent:OF_COMPATIBLE_0=fcu uevent:OF_COMPATIBLE_N=1 uevent:MODALIAS=of:NfanTfcuCfcu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
therm_pm72 units, interface
About a week ago, an XServe G5 of mine started powering off more or less randomly (after 1 hour, chances were good it for it to occur). A problematic UPS has already been cut from the loop, and today I cleaned the machine inside out with pressurized air. So far it runs, for now at least, with a load = 2.0, but I am keeping an eye on whether this is a thermal issue. To that end, I wanted to obtain some statistics. Despite sensors-detect(8) loads lm87.ko for me, running sensors(1) shows no sensors. Oddly enough, I found a kfand process running that seems to stem from therm_pm72.ko, which brings me to the sysfs files. Is there a reason sensors(1) is not supported for Rackmac3,1? Certain sysfs files have a value with an unknown unit. current is likely in Ampere, temperature must be in Celsius (because there's no way the server room is 54°F=12°C cold). Is there a way to obtain the trip points for the hardware? $ cd /sys/devices/temperature; grep '' *; backside_fan_pwm:32 backside_temperature:54.000 cpu0_current:34.423 cpu0_exhaust_fan_rpm:5340 cpu0_intake_fan_rpm:5340 cpu0_temperature:72.889 cpu0_voltage:1.252 cpu1_current:34.179 cpu1_exhaust_fan_rpm:4584 cpu1_intake_fan_rpm:4584 cpu1_temperature:68.526 cpu1_voltage:1.259 dimms_temperature:53.000 grep: driver: Er en filkatalog modalias:platform:temperature grep: power: Er en filkatalog slots_fan_pwm:20 slots_temperature:38.500 grep: subsystem: Er en filkatalog uevent:DRIVER=temperature uevent:OF_NAME=fan uevent:OF_FULLNAME=/u3@0,f800/i2c@f8001000/fan@15e uevent:OF_TYPE=fcu uevent:OF_COMPATIBLE_0=fcu uevent:OF_COMPATIBLE_N=1 uevent:MODALIAS=of:NfanTfcuCfcu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Force FB off
On Tuesday 2010-12-14 21:18, Dave Airlie wrote: On Wed, Dec 15, 2010 at 3:41 AM, Jan Engelhardt jeng...@medozas.de wrote: booting with video=off nor video=i915:off has any effect on skipping FB. What is the correct option to stop FB from taking over my boot consoles? For KMS its not fb taking over its the drm i915 driver, nomodeset will stop it however X will no longer work since it relies on the kernel driver. That would make sense. Furthermore I discovered that video=vesafb:off also has no effect, but here it is clear because the source code ignores the return value of fb_get_options, and so ignores any off command. The real strange thing is that video=offb:off on an Apple Xserve G5 PPC64, while probably skipping OFFB initialization, still ends up in a 640x480 mode with a 8x16 font instead of retaining the PROM console/font. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: the printk problem
On Saturday 2008-07-05 00:01, Andrew Morton wrote:
We don't know how much interest there would be in churning NIPQUAD from
the net guys. Interestingly, there's also %C (wint_t) which is a
32-bit quantity. So we could just go and say %C prints an ipv4
address and be done with it. But there's no way of doing that for
ipv6 addresses so things would become asymmetrical there.
struct in6_addr src;
printk(Source address: %p{ipv6}\n, src);
How about %p{feature}?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: the printk problem
On Saturday 2008-07-05 14:52, Vegard Nossum wrote:
On Saturday 2008-07-05 00:01, Andrew Morton wrote:
We don't know how much interest there would be in churning NIPQUAD from
the net guys. Interestingly, there's also %C (wint_t) which is a
32-bit quantity. So we could just go and say %C prints an ipv4
address and be done with it. But there's no way of doing that for
ipv6 addresses so things would become asymmetrical there.
struct in6_addr src;
printk(Source address: %p{ipv6}\n, src);
How about %p{feature}?
Something like this?
+static char *custom_format(char *buf, char *end,
+ const char *fmt, unsigned int fmtlen, void *arg)
I'd use const void *arg here, so nobody gets the idea
that you could modify the argument while printing :)
+{
+ if (!strncmp(fmt, sym, fmtlen)) {
+ char name[KSYM_SYMBOL_LEN];
+ int len;
+ int i;
+
+ len = sprint_symbol(name, (unsigned long) arg);
+ if (len 0)
+ return buf;
+
+ i = 0;
+ while (i len) {
+ if (buf end)
+ *buf = name[i];
+ ++buf;
+ ++i;
+ }
+ }
And I assume it's then as simple as
} else if (strncmp(fmt, nip6, fmtlen) == 0) {
snprintf(buf, end - buf (+1?), NIP6_FMT in expanded form,
NIP6 in expanded form(arg));
}
Hm, that's going to get a big function when everyone adds their
fmttypes.
+
+ return buf;
+}
+
static char *number(char *buf, char *end, unsigned long long num, int base,
int size, int precision, int type)
{
/* we are called with base 8, 10 or 16, only, thus don't need G... */
@@ -648,6 +673,25 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
va_list args)
continue;
case 'p':
+ if (fmt[1] == '{') {
+ const char *cfmt;
+
+ /* Skip the '%{' */
+ ++fmt;
+ ++fmt;
+
Not this?
/* Skip the '%p{' */
fmt += 3;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: the printk problem
On Saturday 2008-07-05 15:50, Vegard Nossum wrote: I think the most elegant solution would be a macro similar to the initcall macros, that adds the custom extensions to a table which is defined by a special linker section. This allows complete decentralization, but I don't think it's possible to do binary search on the names anymore. With an rbtree, you can still do binary search. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: the printk problem
On Saturday 2008-07-05 19:56, Linus Torvalds wrote:
How about %p{feature}?
No.
I _expressly_ chose '%p[alphanumeric]*' because it's basically
totally insane to have that in a *real* printk() string: the end result
would be totally unreadable.
So, and what do you do when you run out of alphanumeric characters?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: drivers/net/fec_8xx config problem
On Wednesday 2008-04-30 21:23, Scott Wood wrote: On Apr 30, 2008, at 2:20 PM, Scott Wood wrote: On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote: I just noticed that the fec_8xx driver is not currently reachable via menuconfig because it depends on 8XX instead of 8xx. [snip] Since nobody has noticed this problem, I'm wondering if this driver is still in (infrequent) use, or if it's been superseded and should be removed, or if I'm just completely missing something with respect to the use of 8XX instead of 8xx. Blame those developers who had the brilliant idea of using lowercase in kconfig symbols (these things emit cosmic particles en masse!) :-) arch/arm/mach-pxa/Kconfig:config PXA3xx ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 1st version of azfs
+config AZ_FS
+ tristate AZFS filesystem support
+ default m
I do not think it should default to anything.
+#define AZFS_SUPERBLOCK_FLAGS MS_NOEXEC | \
+ MS_SYNCHRONOUS | \
+ MS_DIRSYNC | \
+ MS_ACTIVE
+#define AZFS_BDI_CAPABILITIES BDI_CAP_NO_ACCT_DIRTY | \
+ BDI_CAP_NO_WRITEBACK | \
+ BDI_CAP_MAP_COPY | \
+ BDI_CAP_MAP_DIRECT | \
+ BDI_CAP_VMFLAGS
+
+#define AZFS_CACHE_FLAGS SLAB_HWCACHE_ALIGN | \
+ SLAB_RECLAIM_ACCOUNT | \
+ SLAB_MEM_SPREAD
+
Suggest () around the (MS_NOEXEC|...|...)
+enum azfs_direction {
+ AZFS_MMAP,
+ AZFS_READ,
+ AZFS_WRITE
+};
+
+struct azfs_super {
+ struct list_headlist;
+ unsigned long media_size;
+ unsigned long block_size;
+ unsigned short block_shift;
+ unsigned long sector_size;
+ unsigned short sector_shift;
+ unsigned long ph_addr;
+ unsigned long io_addr;
+ struct block_device *blkdev;
+ struct dentry *root;
+ struct list_headblock_list;
+ rwlock_tlock;
+};
Some of these probably should be sometypedef_t or so, to ensure they
have their minimum width on 32-bit. The struct also could have some
reordering to avoid needless padding.
+struct azfs_block {
+ struct list_headlist;
+ unsigned long id;
+ unsigned long count;
+};
+
Same. unsigned long = uint64_t might be needed/helpful/etc.
+static struct azfs_super_list super_list;
+static struct kmem_cache *azfs_znode_cache __read_mostly = NULL;
+static struct kmem_cache *azfs_block_cache __read_mostly = NULL;
NULL is implicit, drop it, save some bytes in the object file.
+static int
+azfs_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev)
+{
+ struct inode *inode;
+
+ inode = azfs_new_inode(dir-i_sb, dir, mode, dev);
+ if (!inode)
+ return -ENOSPC;
+
+ if (S_ISREG(mode))
+ I2Z(inode)-size = 0;
+
+ dget(dentry);
+ d_instantiate(dentry, inode);
+
+ return 0;
+}
Either azfs_mknod(), azfs_new_inode() or init_special_inode() seems
to be missing settings -size to 0 in the !S_IFREG case and
setting -size to something good-looking for S_IFDIR.
+/**
+ * azfs_open - open() method for file_operations
+ * @inode, @file: see file_operations methods
+ */
+static int
+azfs_open(struct inode *inode, struct file *file)
+{
+ file-private_data = inode;
+
+ if (file-f_flags O_TRUNC) {
+ i_size_write(inode, 0);
+ inode-i_op-truncate(inode);
+ }
+ if (file-f_flags O_APPEND)
+ inode-i_fop-llseek(file, 0, SEEK_END);
+
+ return 0;
+}
This looks like duplicate code. Usually the generic fs functions take
care of that, including quota handling which seems to be missing
here if this is continuing to exist.
+ page_prot = pgprot_val(vma-vm_page_prot);
+ page_prot |= (_PAGE_NO_CACHE | _PAGE_RW);
redundant ().
+ for_each_block(ding, super-block_list) {
+ if (!west (ding-id + ding-count == id))
+ west = ding;
+ else if (!east (id + count == ding-id))
+ east = ding;
redundant().
+static struct inode*
+azfs_new_inode(struct super_block *sb, struct inode *dir, int mode, dev_t dev)
+{
+ struct inode *inode;
+
+ inode = new_inode(sb);
+ if (!inode)
+ return NULL;
+
+ inode-i_atime = inode-i_mtime = inode-i_ctime = CURRENT_TIME;
+
+ inode-i_mode = mode;
+ if (dir) {
+ dir-i_mtime = dir-i_ctime = inode-i_mtime;
+ inode-i_uid = current-fsuid;
+ if (dir-i_mode S_ISGID) {
+ if (S_ISDIR(mode))
+ inode-i_mode |= S_ISGID;
+ inode-i_gid = dir-i_gid;
+ } else {
+ inode-i_gid = current-fsgid;
+ }
+ } else {
+ inode-i_uid = 0;
+ inode-i_gid = 0;
+ }
Why not fsuid/fsgid in the else case?
+azfs_statfs(struct dentry *dentry, struct kstatfs *stat)
+{
[...]
+ mutex_lock(sb-s_lock);
+ list_for_each_entry(inode, sb-s_inodes, i_sb_list) {
+ inodes++;
+ blocks += inode-i_blocks;
+ }
+ mutex_unlock(sb-s_lock);
Can this be improved somehow? If
Re: [patch 1/3] ps3: Disk Storage Driver
On Jul 16 2007 18:15, Geert Uytterhoeven wrote: Add a Disk Storage Driver for the PS3: - Implemented as a block device driver with a dynamic major - Disk names (and partitions) are of the format ps3d%c(%u) - Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor doesn't support scatter-gather I wonder what virtualization has to do with a block device driver? Jan -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
